refactor: unify to subscribe mutation via barrier sender

[wenym1]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

After #18210

Previously in #17612 we introduced the subscribe_barrier_mutation method in LocalBarrierManager, so that inputs of actors with upstream can subscribe the mutation of barrier from local barrier worker. In #18104, we introduced a similar subscribe_barrier for actors without upstream to register barrier receiver to local barrier worker. The two methods have similar functionality, and therefore in this PR, we will try to unify to call subscribe_barrier only.

The difference between the two methods is that, in subscribe_barrier_mutation we can specify the starting epoch to subscribe mutation, while subscribe_barrier subscribe to mutation of all barriers to be collected from the actors. We specify the starting epoch in subscribe_barrier_mutation because, it's called in the input(both remote and local input) of actors, and when scale happens, it's possible that an input subscribes barrier mutation at the epoch that scale happens rather than first epoch of the actor. Though inputs may start at epoch later than the first epoch, the merge executor (or receiver executor) that merges all input should start at the first epoch of the actor. Therefore, in this PR, instead of waiting to receive barrier mutation in local and remote input, we change to wait to receive the barrier mutation in the merge executor and receiver executor.

For SnapshotBackfillExecutor, we also introduced a pre-sync mutation mechanism so that the input won't be blocked at fetching mutation of future barrier. The pre-sync mutation mechanism depends on subscribe_barrier_mutation. To remove subscribe_barrier_mutation, we will also remote the pre-sync mutation mechanism. In #18210, we have done some prerequisite works. In this PR, the SnapshotBackfillExecutor will be handled specially when we build actors. The SnapshotBackfillExecutor will hold the raw inputs instead of merge executor at the beginning. During snapshot backfill, it receives DispatcherBarrier from the raw inputs, and all upstream mutations will be ignored in SnapshotBackfillExecutor during backfill. After snapshot backfill finishes, we will turn the raw inputs into merge executor, and then we consume the upstream as usual. Some refactors are done accordingly in merge executor and receiver executor.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[wenym1]

I think it's safe to ignore the is_stop in the SelectReceiver, because the merge executor stops when seeing the stop barrier, and should not poll the SelectReceiver later.

[hzxa21]

LGTM for changes in barrier manager and snapshot backfill.

@BugenZhao Can you help review the changes in executor/merge.rs?

[BugenZhao]

Generally LGTM (cause I may not have sufficient knowledge on the background).