[multistage] Initial (phase 1) Query runtime for window functions with ORDER BY within the OVER() clause

[somandal]

This PR introduces the multi-stage runtime changes to support Phase 1 of Window Functions, specifically targeting queries of the type OVER(ORDER BY) and OVER(PARTITION BY key1 ORDER BY key2). Runtime support has been added for the following classes of window queries:

• OVER(ORDER BY) - single and multiple OVER(ORDER BY) in the same query
• OVER(PARTITION BY key1 ORDER BY key2) - single and multiple OVER(PARTITION BY key1 ORDER BY key2) using the same PARTITION BY key1 and ORDER BY key2 across all OVER()s in the same query

The window functions supported as part of Phase 1 are: SUM, AVG, MIN, MAX, COUNT, BOOL_OR, and BOOL_AND.

• Design document: https://docs.google.com/document/d/13CmFm4djI09JKF_Xty5acoXxJoxC9CLXAsmikgzgtIs/edit?usp=sharing
• Window functions Issue: [multistage] Support Window Functions #7213
• Window Function Planner PR: [multistage] Initial (phase 1) query planner support for window functions #10228
• Window Functions Runtime PR for empty OVER() and OVER(PARTITION BY): [multistage] Initial (phase 1) Query runtime for window functions - empty OVER() and OVER(PARTITION BY) #10286
• Adding ordering as a part of the SortExchange: [multistage] Implement ordering for SortExchange #10408

This PR does not include support for:

• Custom frames
• Other window functions related to rank and values
• Multiple window groups (basically multiple OVER clauses with different PARTITION BY, ORDER BY and/or FRAME specifications, if these specifications are the same they get grouped into a single window group)

The above will be part of future changes for window function support

Note: One issue was found while working on this PR related to Apache Calcite parsing. Details can be found in this section of the design document. Look for heading "Calcite Parser Exception on ORDER BY with > 1 column using default frame"

cc @siddharthteotia @walterddr @vvivekiyer @ankitsultana

[codecov-commenter]

Codecov Report

Merging #10449 (f6273ac) into master (3687b2b) will decrease coverage by 39.08%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #10449       +/-   ##
=============================================
- Coverage     63.23%   24.16%   -39.08%     
+ Complexity     5905       58     -5847     
=============================================
  Files          2036     2065       +29     
  Lines        110973   111457      +484     
  Branches      16892    16990       +98     
=============================================
- Hits          70177    26930    -43247     
- Misses        35606    81757    +46151     
+ Partials       5190     2770     -2420     

Flag	Coverage Δ
integration1	?
integration2	24.16% <0.00%> (-0.21%)	⬇️
unittests1	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...uery/runtime/operator/WindowAggregateOperator.java	0.00% <0.00%> (-91.67%)	⬇️
...query/runtime/operator/utils/AggregationUtils.java	0.00% <0.00%> (-96.50%)	⬇️

... and 1347 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[walterddr]

looks good mostly.
this PR assumes the mailbox receive will generate ordered block appropriately, correct? if so could we please state so in the javadoc of window aggregate operator?

[somandal]

this PR assumes the mailbox receive will generate ordered block appropriately, correct? if so could we please state so in the javadoc of window aggregate operator?

Thanks for the review! Yes, this PR assumes that mailbox receive will generate ordered blocks. Added a note in the javadocs about this. I've also addressed all other comments. PTAL when you get a chance.

[walterddr]

lgtm