This PR checks for trivial no-op slices in all layout types that essentially do nothing. If that's the case we can directly return self instead of constructing new python classes (and loosing their cached_properties), doing plenty of unnecessary repetitive checks, etc.

The most common operation that benefits from this improvement are __setitem__ calls on RecordArrays, see the following:

from coffea.nanoevents import NanoEventsFactory

events = NanoEventsFactory.from_root({"nanoaod.root": "Events"}, mode="eager").events()

# before this PR
%timeit events["Jet"] = events["Jet"]
10.4 ms ± 14.8 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

# after this PR -> 32x speedup
%timeit events["Jet"] = events["Jet"]
327 μs ± 1.79 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

# or nested:
# before this PR
%timeit events["Jet", "pt"] = events["Jet", "pt"]
11.2 ms ± 250 μs per loop (mean ± std. dev. of 7 runs, 100 loops each)

# after this PR -> 16x speedup
%timeit events["Jet", "pt"] = events["Jet", "pt"]
700 μs ± 5.31 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

Similar speedups are seen for VirtualNDArrays.

I expect this to speedup multiple other operations that traverse layouts as well.

Adding this to TypeTracerArrays is maybe possible (?) but much more complicated as the slices can be TypeTracerArrays themselves and thus need special & careful handling. I tried this, but the full logic turned out to be a bit complicated, and needs more thoughts -> maybe something for a future PR.

This improvement should become pretty noticeable in coffea analysis as it is highly common to store new fields on events, and currently that's one of the most expensive operations - even more expensive than running awkward kernels. And that should not be the case given that this is a metadata only operation.

This PR is reducing the total number of python allocations (new instances, etc) for a single events["Jet", "pt"] = events["Jet", "pt"] setitem from 8049 to 1692.