feat(namespace): support namespaces and numbered databases in cluster mode

[Abhinav2656]

Resolves: #3231

What this PR does / why we need it:
This PR removes the restrictions that previously prevented the use of multiple namespaces and numbered databases when cluster mode is enabled.

Specifically, it:

• Removes the kErrClusterModeEnabled rejection logic in src/server/namespace.cc to allow namespace creation and modification under cluster mode.
• Removes the configuration initialization guards in src/config/config.cc that forced a failure when both cluster_enabled and namespace tokens/databases were present.
• Ensures namespace configurations are correctly written to the persistent store regardless of the cluster state by removing the early return block.

Brief test explanation:

• Re-compiled successfully with native C++ tests passing.
• Executed and passed the Go integration tests specifically for unit/namespace (go test ./unit/namespace ...) under the tests/gocase suite.

Please let me know if any architectural adjustments are required. I am fully open to your review and stand ready to iterate on this logic as needed.

[PragmaTwice]

Thanks for the contribution, but simply dropping these checks doesn't actually make namespaces work in cluster mode.

[Abhinav2656]

Understood. I see now that removing the restrictions only exposes the lack of cluster-aware namespace routing and replication underneath. To ensure I build this correctly, could you point me toward the specific areas in the cluster topology or replication logic that need to be adapted to fully support namespace propagation?

[jihuayu]

Hi @Abhinav2656. Thank you for your PR.

This is a fairly large project. Slot migration/cleanup still only handles __namespace by default, and we also need to consider whether slot mappings should be isolated across tenants. If you're interested in working on this, you can start by putting together a proposal.

[Abhinav2656]

Hey @jihuayu, thanks for reviewing the PR and for the opportunity! I’m really excited to tackle a project of this scale. You raise a crucial point regarding the default namespace limitations and the need for proper tenant isolation across slot mappings.

To ensure we get the architecture right, I’m going to put together a detailed proposal/blueprint outlining how we handle these boundaries during migration. I'll share it here for your feedback first, and once we're completely aligned on the design, I'll move to the implementation.

[jihuayu]

Hey @jihuayu, thanks for reviewing the PR and for the opportunity! I’m really excited to tackle a project of this scale. You raise a crucial point regarding the default namespace limitations and the need for proper tenant isolation across slot mappings.

To ensure we get the architecture right, I’m going to put together a detailed proposal/blueprint outlining how we handle these boundaries during migration. I'll share it here for your feedback first, and once we're completely aligned on the design, I'll move to the implementation.

You can submit proposals in discussions. We will talk in it.