fix: cartesian nested record

[agoose77]

Fixes #2928, by normalising string field names to integers.

This code could be further refactored; it's becoming clear that our recursively_apply abstraction would benefit from better support for smarter continuations (i.e. re-entrant with a different callable). That can be tackled later, though.

[jpivarski]

I've been scanning over the code and I don't see how it changes things. Previously, the name nested was reused, which is bad practice—naming the possibly-new list nested_as_index is a good idea. But I didn't see any further uses of nested that were previously getting clobbered.

Is it a function-scoping issue? Python has a gotcha in which functions defined in a loop that close over a variable that changes in the loop don't end up with the value of the variable at the time when the function was defined, but at the time when the function is called—that can be tricky. But there aren't any loops here.

I don't see how it does it, but it evidently does make a difference. Some of the tests are failing: are they stale expected values, derived based on the old, wrong behavior?

[agoose77]

@jpivarski I introduced a new bug with this PR — I changed tack during fixing of the bug and must have stepped too far back in the editor history. I had thought that such a simple fix would not break anything else, so I didn't touch the local testing and let the CI handle it! That shows me!

As for the change itself, the issue was indeed that we're using nested to mean too many things. Now, it's clear that we test indices against nested_as_index, which ensures the cause of the original bug (test for axis name in list of integers) can't happen.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (e86b149) 81.94% compared to head (1cb67ec) 81.95%.

Additional details and impacted files

Files	Coverage Δ
src/awkward/operations/ak_cartesian.py	91.00% <100.00%> (+0.37%)	⬆️