tracking: stream values executor

[st1page]

the old design does not consider the failover very well, waiting for a new design

We used to think users do not need stream values in streaming queries. But now we found it: #7854
Now we can not support the constant Rows in our streaming execution because we have not supported StreamValuesExecutor.

• Refactor on the barrier receiving.
  • refactor(streaming): decoupling receive barrier logic in a single executor #7856
• Support StreamValues plan node in the optimizer.
• Rewrite LogicalValues to StreamBarrierRecv + StreamValues + StreamRowIdGen in the optimizer.
  • streaming: support StreamValues #8635
• Enrich the AddMutation to check whether the executor is fresh-start.
• Streaming Values executor.

[BugenZhao]

• Rewrite LogicalValues to StreamBarrierRecv + StreamValues + StreamRowIdGen in the optimizer.

Note: this part might be tricky, as after we attach the RowIdGen node to the plan, the schema of the Values is changed. So this should be done in logical_rewrite_for_stream and maybe we also need to introduce the logical one of RowIdGen.

• Streaming Values executor.

This can simply behave like a trivial Chain executor which embeds the expression evaluation, that is, we evaluate the expression in a blocking manner and output all of the results during the first epoch. It's worth noting that...

• like Chain, if we find that we're on fail-over, we should not output again
• like Chain, this should also be treated as a part of the executors that are tracked for the creating materialized view progress.