perf: Avoid copying when materializing output in OrderedPartialAggregateStream

[2010YOUY01]

Which issue does this PR close?

part of #25157

Rationale for this change

Cause

See issue for the target query.

The query plan looks like

Query plan, Click to expand

> explain SELECT count(*) FROM (
  SELECT DISTINCT d_year, brand, class, cat, manu, cnt, amt FROM src
);
+---------------+-------------------------------+
| plan_type     | plan                          |
+---------------+-------------------------------+
| physical_plan | ┌───────────────────────────┐ |
|               | │       ProjectionExec      │ |
|               | │    --------------------   │ |
|               | │         count(*):         │ |
|               | │      count(Int64(1))      │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │       AggregateExec       │ |
|               | │    --------------------   │ |
|               | │       aggr: count(1)      │ |
|               | │        mode: Final        │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │   CoalescePartitionsExec  │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │       AggregateExec       │ |
|               | │    --------------------   │ |
|               | │       aggr: count(1)      │ |
|               | │       mode: Partial       │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │       ProjectionExec      │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │       AggregateExec       │ |
|               | │    --------------------   │ |
|               | │         group_by:         │ |
|               | │ d_year, brand, class, cat,│ |
|               | │       manu, cnt, amt      │ |
|               | │                           │ |
|               | │           mode:           │ |
|               | │      FinalPartitioned     │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │      RepartitionExec      │ |
|               | │    --------------------   │ |
|               | │ partition_count(in->out): │ |
|               | │          14 -> 14         │ |
|               | │                           │ |
|               | │    partitioning_scheme:   │ |
|               | │  Hash([d_year@0, brand@1, │ |
|               | │   class@2, cat@3, manu@4  │ |
|               | │    , cnt@5, amt@6], 14)   │ |
|               | │                           │ |
|               | │    preserve_order: true   │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │       AggregateExec       │ |
|               | │    --------------------   │ |
|               | │         group_by:         │ |
|               | │ d_year, brand, class, cat,│ |
|               | │       manu, cnt, amt      │ |
|               | │                           │ |
|               | │       mode: Partial       │ |
|               | └─────────────┬─────────────┘ |
|               | ┌─────────────┴─────────────┐ |
|               | │       DataSourceExec      │ |
|               | │    --------------------   │ |
|               | │         files: 14         │ |
|               | │      format: parquet      │ |
|               | └───────────────────────────┘ |
|               |                               |
+---------------+-------------------------------+

It's slow due to inefficient output materializing in partial and final aggregation

For internal mechanism, this comment explains 'why not X, and do Y instead' -- X is the existing impl, Y is what this PR does.

• https://github.com/2010YOUY01/arrow-datafusion/blob/0f165d0129820a3bd66641609d9efb954c0cc018/datafusion/physical-plan/src/aggregates/ordered_partial_stream.rs#L219-L248

Fix

To fully restore the performance, we have to fix:

1. Ordered partial aggregation (this PR)
2. Ordered final aggregation (maybe a follow-up PR)

2 uses almost the same mechanism as 1, so once this PR is reviewed, we can apply the pattern mechanically.

After this PR, the query runs in: (on an M4 Pro MacBook Pro)

-- Still some gap due to final aggregation is not fixed yet
Current main: 3.5s
PR: 0.45s
DataFusion 54.0: 0.37s

What changes are included in this PR?

1. Refactor the ordered-partial aggregation, so it's easier to implement incremental outputting with slicing
2. Implement the output materializing strategy mentioned above

Note to read this PR, I suggest directly reading the new impl start from the entry point of state machine (into_stream()), instead of the diff, due to a large refactor.
This refactor is necessary because its easier to implement this feature with a different state machine pattern.

What is the testing strategy for this PR?

For correctness, existing tests have covered it.
To prevent similar perf regression, we can do

• Microbenchmark for aggregation #25310

Are there any user-facing changes?

[codecov-commenter]

Codecov Report

❌ Patch coverage is 91.12903% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.92%. Comparing base (9082d6b) to head (1950fb2).
⚠️ Report is 24 commits behind head on main.

Files with missing lines	Patch %	Lines
...ical-plan/src/aggregates/ordered_partial_stream.rs	88.54%	3 Missing and 8 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #25312      +/-   ##
==========================================
+ Coverage   81.88%   81.92%   +0.03%     
==========================================
  Files        1133     1134       +1     
  Lines      424522   425899    +1377     
  Branches   424522   425899    +1377     
==========================================
+ Hits       347623   348916    +1293     
- Misses      56285    56303      +18     
- Partials    20614    20680      +66     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.