GH-38558: [C++] Add support for null sort option per sort key

[taepper]

See #38584 for original PR. Will be quoted for this PR description.

Rationale for this change

support multi sortkey nulls first.

order by i nulls first, j, k nulls first;

The current null sorting only supports all sortkeys, not a certain sortkey, so NullPlacement is extended to the SortKey field. Since the underlying framework is very well written, when modifying this function, you only need to pass the null_placement of each SortKey in. That’s it.

What changes are included in this PR?

1.SortKey structure, NullPlacemnt transfer logic, sorting logic and Ording related, test related
2.Substriait related.
3.c_glib related.
4.SelectK related.
5.RankOptions related.

Are these changes tested?

yes, I changed the code inside vector_sort_test.cc and performed additional tests.

Are there any user-facing changes?

yes, pg database include null sorting of multiple sort keys.

This PR includes breaking changes to public APIs. (If there are any breaking changes to public APIs, please explain which changes are breaking. If not, you can remove this.)

I amended the original PR to be less breaking in public APIs.

Still Ordering, SortOptions, RankOptions, and RankQuantileOptions now accept a std::optional<NullPlacement> instead of NullPlacement, which did lead to some changes in downstream APIs and bindings. I also need some help with fixing the c_glib bindings.

• GitHub Issue: [C++][Compute] Fix null sorting of multiple sort keys #38558

[taepper]

Thank you for the review. I was not sure regarding the introduction of std::span usage, which I find very succinct.

For example, also this std::ranges:: based for-loop replacement has now been detected by my local clangd:

for (uint64_t& reverse_out_iter : std::ranges::reverse_view(output.non_null_like_range))
{...}

instead of

for (auto reverse_out_iter = output.non_null_like_range.rbegin();
     reverse_out_iter != output.non_null_like_range.rend(); reverse_out_iter++) {

Feel free to let me know if these code-style preferences are not wanted

[taepper]

Of course I will rebase onto main and update the code deprecation references to 25.0.0 from 24.0.0, but did no want to introduce noise to the history for now. When you are okay with the approach, I will rebase

[pitrou]

Thank you for the review. I was not sure regarding the introduction of std::span usage, which I find very succinct.

For example, also this std::ranges:: based for-loop replacement has now been detected by my local clangd:

Oh, yes, these are nice additions, thank you.

[pitrou]

The temporary storage of all indices for the individual chunks could still be a bit better. Maybe I should introduce a struct that holds all three of array, indices and partitions?

I don't think we care in this PR. Otherwise we have CompressedChunkLocation that can make things more compact.

[pitrou]

Of course I will rebase onto main and update the code deprecation references to 25.0.0 from 24.0.0, but did no want to introduce noise to the history for now. When you are okay with the approach, I will rebase

Actually, please rebase now, I think it will make local testing easier.

[taepper]

Of course I will rebase onto main and update the code deprecation references to 25.0.0 from 24.0.0, but did no want to introduce noise to the history for now. When you are okay with the approach, I will rebase

Actually, please rebase now, I think it will make local testing easier.

Okay, the merge actually had no conflicts, so my wariness was not necessary

[pitrou]

LGTM, just two nits. Assuming CI is green, we'll be able to merge this.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 1926639.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 15 possible false positives for unstable benchmarks that are known to sometimes produce them.