Fix the companion function changes step behavior

[jinchengchenghh]

Before that, the count result is incorrect. For companion aggregate function, the step of all the aggregates can be different, facebookincubator#12830 (comment), in this example, HashAggregate(keys=[], functions=[merge_count(l_quantity#80), partial_count(distinct l_partkey#77L)], output=[count#166L, count#169L]), so we cannot use a single step for HashAggregation

the step is SINGLE the kind is sum_merge_extract
the step is SINGLE the kind is sum_merge_extract
the step is SINGLE the kind is count_merge_extract
add input 14count reduce stepSINGLE
count input 0: {11933.739999999998, -4828.52, 8}
1: {13683.73, -100.96000000000026, 6}
2: {7070.17, 289.63, 8}
3: {13205.7, -952.0400000000004, 8}
4: {7017.68, 4809.41, 5}
5: {129.12, -27.13000000000001, 2}
6: {23060.460000000003, 6369.129999999999, 10}
7: {15549.43, -6224.07, 8}
8: {8111.89, -14071.19, 4}
9: {12510.16, -309.84000000000106, 8}
10: {4638.43, -7112.44, 5}
11: {9982.08, -4268.39, 7}
12: {11483.15, 2080.0799999999995, 8}
13: {1447.4599999999998, -20.260000000000105, 3}
get the output 1
[14,139823.2,-24366.590000000004]                                               
Elapsed time: 4.389513118 seconds

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[bdice]

Would this failure be reproducible in a Velox test? Could we add a test?

[bdice]

/ok to test 27e6113

[devavret]

@jinchengchenghh Thanks for this PR. Can you add a bit of context on what these functions are? I wasn't aware that functions can dictate their step. This will likely affect streaming aggregations #6 because they rely on the step of the plannode.