refactor(batch): maintain serving vnode mapping in meta node

[zwang28]

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

What's changed and what's your intention?

Refactor decentralized serving vnode mapping placement strategy to centralized one in meta node.

• Use a rebalance strategy place_vnode, similar to streaming's rebalance_actor_vnode, keeping vnodes balanced among parallel units with minimal reshuffle.
• Mapping is not persisted, only exists in meta node's memory.
• All mapping changes in meta node are broadcast to frontends.
• Whenever meta node starts, mapping is calculated from scratch (for all fragments one by one independently).
• Whenever compute node joins/leaves, mapping is rebalanced (for all fragments one by one independently).
• Whenever fragment is added/removed, its mapping is added/removed corresponding asynchronously.

Note that, meta node restarts may cause some reshuffle, because a mapping calculated from scratch can be different from a mapping that has applied several rebalances. For example, assume total vnode count is 9, given [pu1, pu2, pu4].

• mapping_1 is calculated from scratch and results in [ pu1: (v1,v4,v7); pu2: (v2,v5,v8); pu4: (v3,v6,v9) ]
• mapping_2 is rebalanced several times:
  1. it's firstly calculated from scratch given [pu1, pu2, pu3], results in [ pu1: (v1,v4,v7); pu2: (v2,v5,v8); pu3: (v3,v6,v9) ]
  2. then pu4 is added, rebalance results in [ pu1: (v1,v4,v7); pu2: (v2,v5); pu3: (v3,v6); pu4: (v8, v9) ]
  3. then pu3 is removed, rebalance results in [ pu1: (v1,v4,v7); pu2: (v2, v3, v5); pu4: (v6, v8, v9) ], which is not equal to mapping_1.

#8940

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

• I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

• My PR DOES NOT contain user-facing changes.

Click here for Documentation

Types of user-facing changes

Please keep the types that apply to your changes, and remove the others.

• Installation and deployment
• Connector (sources & sinks)
• SQL commands, functions, and operators
• RisingWave cluster configuration changes
• Other (please specify in the release note below)

Release note

[codecov]

Codecov Report

Merging #10004 (b909f63) into main (a6f38d9) will decrease coverage by 0.05%.
The diff coverage is 47.94%.

@@            Coverage Diff             @@
##             main   #10004      +/-   ##
==========================================
- Coverage   70.53%   70.49%   -0.05%     
==========================================
  Files        1243     1245       +2     
  Lines      213006   213437     +431     
==========================================
+ Hits       150252   150459     +207     
- Misses      62754    62978     +224     

Flag	Coverage Δ
rust	70.49% <47.94%> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/common/common_service/src/observer_manager.rs	38.61% <0.00%> (-0.39%)	⬇️
src/frontend/src/observer/observer_manager.rs	0.00% <0.00%> (ø)
src/frontend/src/scheduler/distributed/stage.rs	15.65% <0.00%> (-0.03%)	⬇️
src/frontend/src/scheduler/error.rs	8.33% <ø> (ø)
src/frontend/src/scheduler/local.rs	0.00% <0.00%> (ø)
src/meta/src/barrier/command.rs	37.07% <0.00%> (ø)
src/meta/src/batch/mod.rs	0.00% <0.00%> (ø)
src/meta/src/dashboard/mod.rs	0.00% <ø> (ø)
src/meta/src/lib.rs	0.00% <ø> (ø)
src/meta/src/manager/notification.rs	76.92% <ø> (ø)
... and 15 more

... and 8 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[soundOfDestiny]

Should we specialize for initial case to get better performance?

[liurenjie1024]

Generally LGTM for the framework, but please add some comments to the core method.