refactor: use 1 for vnode count of singletons

[BugenZhao]

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

What's changed and what's your intention?

This is a progress towards #15900.

Try to address #18515 (comment), i.e., use 1 for vnode count of singletons. There are several cases to consider:

• Use 1 for vnode count for all singleton fragments or tables to create in the current version.
  • There can be (effectively) singleton table within a distributed fragment, typically the state table of Source executor. In this case, we still treat it as singleton and assign it with 1 as the vnode count.
  • As a result, the vnode_count of a state table is not always the same as the length of the vnode_bitmap of its associated fragment. This should be correctly handled while performing batch scans over them.
• VnodeCountCompat::vnode_count should return 1 for structures persisted before, if they are believed to be singleton.
• For SQL backend, correctly perform the migration to fill 1 for the vnode_count field of singletons. The logic here must be consistent with the one in VnodeCountCompat::vnode_count, as under SQL backend, we still have some table catalogs persisted in form of protobuf, like the internal table catalogs in plan nodes.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

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.

[BugenZhao]

• refactor: use 1 for vnode count of singletons #18753 👈
• fix(meta): align job's max parallelism while replacing table #19052
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @BugenZhao and the rest of your teammates on Graphite

[BugenZhao]

This reveals a severe bug that we persist and notify about the internal tables before the vnode counts are correctly resolved, leading to inconsistency between the stream nodes and the catalog.

[BugenZhao]

This reveals a severe bug

Will first fix in #18759

[BugenZhao]

This PR has been significantly reworked. Please review it again based on the updated PR body. 🥰

[BugenZhao]

If we can get this PR into release 2.1, we don't need a new migration step but only to update this existing one.

[BugenZhao]

Decide to include this PR in v2.2 instead. Switch to a new migration file.