Tracking: batch query memory control and spill

[chenzl25]

Currently, RisingWave batch queries can easily consume too much memory without limitation. This is a great threat to our system's stability. To resolve this issue, we can first implement memory control logic to ensure that if batch queries consume more memory than the reserved memory limit, we can abort a batch query quickly to avoid a potential OOM. The memory check could be implemented on operators that could consume a large amount of memory, e.g. HashAgg, Hash Join, and so on. After we have a memory control logic which means now we know exactly the moment of not enough memory, we can implement a spill-to-disk algorithm for those batch operators.

• batch query memory control feat: support memory limit for batch queries #16616
• spill hash join: Grace hash join/ Hybrid hash join feat(batch): support spill hash join #17122
• spill hash agg: use the same idea of the spill version of hash join RFC: Spill Hash Aggregation rfcs#89
• spill sort: refactor(batch): support merge sort executor #17306
• spill metrics: feat(metrics): add metrics for batch spilling #17259