RONDB-822 pushdown-aggregation bugfix

[KernelMaker]

Description:
it's not a bug and works fine in the release binary.
The assertion was added to ensure everything behaves as I expected.
Specifically, I wanted to verify that when LQH sends scanfragconf to TC,
no aggregation results remain cached unless:

We are scanning and aggregating an empty table.

No rows meet the filter condition.

It's the end of the scan.

Under these conditions, the scanPtr->scanState should change to
ScanRecord::WAIT_CLOSE_SCAN.

However, this case help us catch an new exception:
When performing an index scan on an empty table, dbtux directly
returns ZEMPTY_FRAGMENT, skipping the state transition from
ScanRecord::WAIT_ACC_SCAN to ScanRecord::WAIT_CLOSE_SCAN. This
behavior causes the assertion to trigger. The root cause lies in the
different ways dbtux and dbtup handle empty tables during
execACC_SCANREQ.

Solution:
Add ScanRecord::WAIT_ACC_SCAN to the assertion to account for this
scenario.

[svenssonaxel]

The result file has diffs indicating a bug in null handling. I'm not sure whether this bug is in RonSQL or PDAgg. If you don't want to fix the bug, at least remove the diff lines, causing the test case to fail, open a ticket and edit mysql-test/suite/ronsql/disabled.def by updating the ticket number. If you do fix it, the diff lines should be removed when running the case with --record, and you can remove the case from disabled.def.

[svenssonaxel]

This diff indicates another bug in how null values are handled.

[svenssonaxel]

Same.

[svenssonaxel]

Same.

[svenssonaxel]

Same.

[KernelMaker]

Thank you for the review! @svenssonaxel
Regarding the diff-issue, I think it requires RonSQL to handle the default NULL result based on different aggregation operations. As shown in this example, when performing aggregation on an empty table, COUNT() behaves differently on MySQL compared to other operations in handling NULL.
Since it’s an empty table, the aggregator on the data node doesn’t get a chance to perform any actual calculations. It simply returns the same default aggregation result (NULL) for all operations. This necessitates handling the result on the RonSQL side. Specifically, COUNT(), converts its result to zero instead of leaving it as NULL.
If you agree with it, we can proceed with merging this patch first, and then you can take the next steps based on it.

[KernelMaker]

.result updated

[svenssonaxel]

@KernelMaker Sounds great! Kindly create a ticket and update disabled.def, then we can merge.

[KernelMaker]

@svenssonaxel Done.

[svenssonaxel]

I believe you meant RONDB-831.