Better optimization of consecutive keys in aggregation - #57872

TTLAggregationAlgorithm built its Aggregator::Params with
min_chunk_bytes_for_parallel_parsing in the argument slot that expects
min_hit_rate_to_use_consecutive_keys_optimization. The former is a byte
threshold defaulting to 10 MiB, the latter a hit rate in [0, 1] defaulting
to 0.5, so the threshold arrived as 10485760.0.

Aggregator::executeImpl compares cache_hit_rate (at most 1.0) against that
threshold, so use_cache was always false, Method::StateNoCache was selected,
and StateImpl<false>::hasOnlyOneValueSinceLastReset() returns false
unconditionally. That value gates the equal-key-range batching in
executeAggregateInstructions, so addBatchSinglePlace was never taken and the
consecutive keys optimization was permanently disabled for TTL GROUP BY
aggregation. This is the path that benefits most from it: execute() calls
calculateAggregates() once per run of equal keys, so every executeOnBlock
receives a single-key chunk.

Introduced by ClickHouse#57872, which added the parameter and used the correct setting
at every other call site; the narrowing conversion that would have flagged it
was later silenced by the static_cast<float> from ClickHouse#94643. Present since
v23.12.1.1368-stable. Results are not affected, only performance.

There is no parallel parsing in this file, so the now-unused
min_chunk_bytes_for_parallel_parsing extern is removed.

Measured on the added test (200000 rows, 100 keys, one aggregating TTL
merge): ProfileEvents['AggregationOptimizedEqualRangesOfKeys'] goes from 0
to 588 while count() and sum(v) stay identical.

Closes: ClickHouse#112075