feat: add has_non_empty_nulls helper function in OffsetBuffer

[rluvaton]

Which issue does this PR close?

N/A

Rationale for this change

In variable-length array types (e.g., StringArray, ListArray), null entries may have non-empty offset ranges, meaning the underlying data buffer contains data behind nulls. This matters when wanting to work on the underlying values of variable length data for example when unwrapping (flattening) a list array, as the child values are exposed, including those behind null entries. If null entries point to non-empty ranges, the unwrapped values will contain data that may not be
meaningful to operate on and could cause errors (e.g., division by zero in the child values).

Usages when this will be helpful:

• flattening list array
• casting lists/map - we don't wanna cast values that are not used so this is a check if there is one
• explode on list - we don't want the null values behind it so this give us a check if it exists (will have another pr to cleanup empty values)
• gc on lists/map/strings to remove unneeded data

What changes are included in this PR?

Add OffsetBuffer::is_there_null_pointing_to_non_empty_value method that checks if any null positions correspond to non-empty offset
ranges

Are these changes tested?

Yes

Are there any user-facing changes?

Yes, a new public method OffsetBuffer::is_there_null_pointing_to_non_empty_value is added.

---

Related to:

• Add lambda support and array_transform udf datafusion#18921 as it need to unwrap the list values and only get the reachable values

[rluvaton]

Would appreciate a review

[alamb]

Thanks @rluvaton -- i reviewed the code and it looks good to me overall

I think we should reconsider the super long name and the seemingly over-large number of tests, but otherwise 👍

[alamb]

this code would be a lot simpler if there were a NullBuffer::invalid_slices 🤔

[rluvaton]

yes but I feel the code is pretty straight forward and this have comments as well that explaining the logic

[alamb]

I think this function name is a little excessively long and doesn't fit with the rest of this codebase. Can you please rename it to something shorter and more concise. Here are some ideas:

1. has_null_data
2. has_non_empty_nulls
3. nulls_have_values
4. has_populated_nulls

[rluvaton]

renamed to has_non_empty_nulls

[alamb]

Do we need all these tests? It seems like a single test for each representative case would be more than adequate and trim this PR down substantially

[rluvaton]

removed some

[alamb]

Thanks @rluvaton -- looks good o me