feat: add ak.merge_union_of_records

[agoose77]

This PR addresses #2182. We already implement some of this machinery in UnionArray, which has a _union_of_optionarrays method to convert from option[union[X, Y, Z]] to union[option[X], Y, ..., Z]. It doesn't seem like that is particularly useful in this case.

Interestingly there is some overlap with ak._util.union_to_record.

Added functions

• ak.merge_option_of_records
• ak.merge_union_of_records

[codecov]

Codecov Report

Merging #2185 (f3ff3b3) into main (a91d96b) will increase coverage by 0.08%.
The diff coverage is 88.76%.

Additional details and impacted files

Impacted Files	Coverage Δ
...c/awkward/operations/ak_merge_option_of_records.py	88.00% <88.00%> (ø)
...rc/awkward/operations/ak_merge_union_of_records.py	88.70% <88.70%> (ø)
src/awkward/operations/__init__.py	100.00% <100.00%> (ø)
src/awkward/operations/ak_where.py	91.83% <0.00%> (ø)
src/awkward/operations/ak_fill_none.py	95.12% <0.00%> (ø)
src/awkward/operations/ak_full_like.py	98.18% <0.00%> (ø)
src/awkward/operations/ak_to_backend.py	100.00% <0.00%> (ø)
src/awkward/operations/ak_with_field.py	100.00% <0.00%> (ø)
src/awkward/contents/recordarray.py	84.91% <0.00%> (+0.41%)	⬆️
src/awkward/index.py	90.44% <0.00%> (+0.63%)	⬆️
... and 2 more

[agoose77]

This is doing something different for is_option. merge_option_of_records

[agoose77]

@jpivarski what I'm not certain on here is what should happen for esoteric layouts that have multiple "option-of-record", and "union-of-record" in a single dimension. What should we do here, first wins? It seems like we do that in ak.drop_none(), but I don't recall us having a rule.

[jpivarski]

I added some tests which include the original problem in #2182 and a variation of it that has already-optional fields (to verify that the simplified classmethod is being used).

I also added tests for the ak.merge_option_of_records, and the result is wrong; it drops Nones, rather than merging them into the record fields. I'm labeling this review as "Approve" because once that's fixed and the tests pass, it will be ready to merge.

Oh, I didn't add any tests for different axis values. Was that straightforward/formulaic? If it follows a pattern set by the many other functions that use axis, then I don't think we need to explicitly test it.

Darn it, I just convinced myself that I really do need to test it. One moment...

Okay, tested it.