Performance: Use a specialized sum accumulator for retractable aggregregates

[alamb]

Which issue does this PR close?

Closes #6878

Rationale for this change

I noticed this while working on #4973

The SUM accumulator is general (it can handle sliding windows) but to be general it carries through an extra count for each group in the "state" -- this count is ignored. For low cardinality groups this likely isn't a problem but for large cardinality groups creating and carrying through the counts takes a measurable amount of time (I saw it in #6800)

What changes are included in this PR?

Use a specialized sum accumulator for retractable windows and only track the counts there. For non

Are these changes tested?

Existing coverage

Performance (the bigger changes like q15 have a sum` in them, so the change is plausible). The smaller changes don't have any sums which makes me suspicious

┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query        ┃ main_base ┃ alamb_sliding_sum ┃        Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 1     │  493.94ms │          482.97ms │     no change │
│ QQuery 2     │  234.61ms │          224.64ms │     no change │
│ QQuery 3     │  166.23ms │          164.85ms │     no change │
│ QQuery 4     │  117.63ms │          113.72ms │     no change │
│ QQuery 5     │  357.76ms │          361.91ms │     no change │
│ QQuery 6     │   38.66ms │           38.06ms │     no change │
│ QQuery 7     │  834.50ms │          845.64ms │     no change │
│ QQuery 8     │  227.74ms │          232.79ms │     no change │
│ QQuery 9     │  522.91ms │          496.78ms │     no change │
│ QQuery 10    │  321.29ms │          313.16ms │     no change │
│ QQuery 11    │  178.21ms │          184.38ms │     no change │
│ QQuery 12    │  159.24ms │          155.57ms │     no change │
│ QQuery 13    │  516.62ms │          487.68ms │ +1.06x faster │
│ QQuery 14    │   48.16ms │           45.60ms │ +1.06x faster │
│ QQuery 15    │   92.66ms │           81.38ms │ +1.14x faster │
│ QQuery 16    │  206.11ms │          193.74ms │ +1.06x faster │
│ QQuery 17    │ 2336.67ms │         2271.10ms │     no change │
│ QQuery 18    │ 2296.14ms │         2242.11ms │     no change │
│ QQuery 19    │  155.26ms │          151.59ms │     no change │
│ QQuery 20    │  770.76ms │          683.80ms │ +1.13x faster │
│ QQuery 21    │ 1078.71ms │         1009.40ms │ +1.07x faster │
│ QQuery 22    │   84.39ms │           88.77ms │  1.05x slower │
└──────────────┴───────────┴───────────────────┴───────────────┘

Are there any user-facing changes?

a little faster performance. I really expect this to help the code in #6800 so I can simplify the sum accumulator

[alamb]

The point of the PR is to remove this "count" field

[alamb]

This follows the same pattern as Sliding{MinMax}Accumulator https://github.com/apache/arrow-datafusion/blob/main/datafusion/physical-expr/src/aggregate/min_max.rs#L664

[Dandandan]

LGTM 👍

[alamb]

FYI @mustafasrepo