refactor: Split hash aggregation logic into separated streams

[2010YOUY01]

Which issue does this PR close?

• part of Split Aggregation Logic into Dedicated Streams #22710
• 1/N of PoC: Blocked state management for hash aggregation #22712

Rationale for this change

See issues.

This PR split out partial and final aggregate strem from GroupsHashAggregateStream

To fully migrate hash aggregation, we have to

• Port this optimization back Skipping partial aggregation when it is not helping for high cardinality aggregates #11627
• Support spilling
  I think they should be leave to follow up PRs

Todo in this PR:

• Add a temporary configuration enable_migration_aggregate to turn off this path

Since it should be a regression if the above features are not added, it also helps if to prevent potential regressions from the migration of other aggregate streams.

What changes are included in this PR?

Split out the streams from GroupsHashAggregateStream

1. Partial stage of hash aggregation
2. Final stage of hash aggregation

Are these changes tested?

Are there any user-facing changes?

[2010YOUY01]

The state machines are identical for now, but in follow-up work, such as skipping partial aggregation for high-cardinality inputs, their control flows will diverge. I think separating them improves clarity, as discussed in #22710.

Some duplication is inevitable, but that is the trade-off.

[2010YOUY01]

cc @Dandandan @ariel-miculas @alamb, who have expressed interest before.

[ariel-miculas]

I'm curious about the high-level vision: is the plan to close #15591 in favor of this new approach?

I would like the redesign of hash aggregation to take into account the memory constraints imposed by the finite memory pool, i.e. how does the implementation perform under OOM conditions.

• how do we improve memory accounting (see Hash aggregation produces batches reporting huge memory size #22526).
• how do we avoid excessive memory allocations during OOM condition (see fix: reduce memory allocation overhead during partial aggregation ear… #22165)
• other issues such as [EPIC] Eliminate Long Polls in HashAggregate via Chunked Storage and Incremental Emission #19906

Otherwise we'll end up with the same issues that exist now. E.g. EmitTo::First(n) wasn't designed for emitting a large portion of the existing groups, so it over-allocated when used for emitting early in partial aggregation OOM case.

[2010YOUY01]

I'm curious about the high-level vision: is the plan to close #15591 in favor of this new approach?

Yes, the goal is to support blocked state management.

The existing challenge is that the current implementation is hard to extend and review. I want to clean things up through this refactor first, and then apply the actual change.

I would like the redesign of hash aggregation to take into account the memory constraints imposed by the finite memory pool, i.e. how does the implementation perform under OOM conditions.

• how do we improve memory accounting (see Hash aggregation produces batches reporting huge memory size #22526).
• how do we avoid excessive memory allocations during OOM condition (see fix: reduce memory allocation overhead during partial aggregation ear… #22165)
• other issues such as [EPIC] Eliminate Long Polls in HashAggregate via Chunked Storage and Incremental Emission #19906

Otherwise we'll end up with the same issues that exist now. E.g. EmitTo::First(n) wasn't designed for emitting a large portion of the existing groups, so it over-allocated when used for emitting early in partial aggregation OOM case.

All of these issues are symptoms of managing state in a large contiguous Vec. Blocked memory allocation should address them naturally.