This change wires the prefix partitions introduced in elastic#144617 to the 
compute engine.

Today, we partition the rate query by interval via replacing round_to 
with query_and_tags. With 10k time-series and a 5-minute bucket, each
interval query reads all 10k time-series from every segment. In the rate
aggregation, we buffer data points for all 10k time-series and maintain
a priority queue across all of them within each interval. This approach
increases concurrency to avoid underutilizing CPUs, but adds overhead
and is not I/O friendly due to fragmented reads.

With prefix partitions, we partition data by groups of contiguous 
time-series instead. For example, 10k time-series can be split into 1024
groups of ~10 each. Each group reads all matching data points, and
because these time-series are co-located in each segment, reads are
sequential and I/O friendly. In the rate aggregation, the priority queue
manages only ~10 time-series per group instead of 10k, significantly
reducing memory usage. To avoid excessive overhead from tiny partitions,
we merge adjacent partitions up to a target size (250k docs).

When prefix partitioning is not available (e.g., older codec without 
prefix layout), we fall back to the current behavior

This change wires the prefix partitions introduced in elastic#144617 to the 
compute engine.

Today, we partition the rate query by interval via replacing round_to 
with query_and_tags. With 10k time-series and a 5-minute bucket, each
interval query reads all 10k time-series from every segment. In the rate
aggregation, we buffer data points for all 10k time-series and maintain
a priority queue across all of them within each interval. This approach
increases concurrency to avoid underutilizing CPUs, but adds overhead
and is not I/O friendly due to fragmented reads.

With prefix partitions, we partition data by groups of contiguous 
time-series instead. For example, 10k time-series can be split into 1024
groups of ~10 each. Each group reads all matching data points, and
because these time-series are co-located in each segment, reads are
sequential and I/O friendly. In the rate aggregation, the priority queue
manages only ~10 time-series per group instead of 10k, significantly
reducing memory usage. To avoid excessive overhead from tiny partitions,
we merge adjacent partitions up to a target size (250k docs).

When prefix partitioning is not available (e.g., older codec without 
prefix layout), we fall back to the current behavior

This change wires the prefix partitions introduced in elastic#144617 to the 
compute engine.

Today, we partition the rate query by interval via replacing round_to 
with query_and_tags. With 10k time-series and a 5-minute bucket, each
interval query reads all 10k time-series from every segment. In the rate
aggregation, we buffer data points for all 10k time-series and maintain
a priority queue across all of them within each interval. This approach
increases concurrency to avoid underutilizing CPUs, but adds overhead
and is not I/O friendly due to fragmented reads.

With prefix partitions, we partition data by groups of contiguous 
time-series instead. For example, 10k time-series can be split into 1024
groups of ~10 each. Each group reads all matching data points, and
because these time-series are co-located in each segment, reads are
sequential and I/O friendly. In the rate aggregation, the priority queue
manages only ~10 time-series per group instead of 10k, significantly
reducing memory usage. To avoid excessive overhead from tiny partitions,
we merge adjacent partitions up to a target size (250k docs).

When prefix partitioning is not available (e.g., older codec without 
prefix layout), we fall back to the current behavior