feat: introduce batch execution mode

[aglinxinyuan]

What changes were proposed in this PR?

We are introducing a batch execution mode alongside the existing streaming execution mode.

To support this, a new workflow setting called execution mode has been added, along with a corresponding backend flag. Batch and streaming execution are treated as the same level and are represented as an enum in the configuration.

We also introduce a flag named defaultExecutionMode, whose value is set to streaming.

Execution Mode	Demo
Streaming
Batch

Any related issues, documentation, discussions?

This PR resolves issue #4157.

How was this PR tested?

Tested using the existing test cases. TBA.

Was this PR authored or co-authored using generative AI tooling?

No.

[aglinxinyuan]

I will mark this PR ready after adding test cases.

[Yicong-Huang]

I don't think this setting should be part of Physical plan. The information is already in workflowContext, why duplicate it again in physical plan?

[Yicong-Huang]

In fact, please do not add such configuration to physical plan.

[aglinxinyuan]

Before doing this PR, Xiaozhen, Chen, and I discussed this and agreed that this flag should be part of the physical plan. Given how the CostBasedScheduleGenerator uses blocking output links in the physical plan to reason about regions, this information belongs in the physical plan. We are not duplicating information in the physical plan; we use this information to generate a new physical plan. In fact, the physical plans for streaming mode and batch mode are different, because the physical plan includes the links, and in batch mode every output link becomes a blocking link.

[Yicong-Huang]

I cannot agree.

I think physical plan should be exactly same, no matter how we execute it. If it got changed then we need to revisit previous decisions. The execution plan will be different, based on how we cut the regions and how we do materializations.

[aglinxinyuan]

I don’t think it’s true that the physical plan will be exactly the same regardless of how we execute it. If you look at the line 52, this.physicalPlan = updatedPhysicalPlan, the physical plan clearly changes before and after CostBasedScheduleGenerator, so the physical plan changes based on the execution plan.
We may need input from @Xiao-zhen-Liu to understand why Pasta needs to modify the physical plan and whether this behavior is intentional.

[Xiao-zhen-Liu]

Pasta does not modify the physical plan. We can still keep the physical plan immutable for this PR by pushing the logic of marking all edges as materialized inside Pasta.