[3.3] Remove Config migration compatibility logic

[KomachiSion]

Background

Nacos 3.x still keeps compatibility migration logic for Config data upgraded from versions before 3.0. The main compatibility paths are:

• default namespace storage migration between legacy empty tenant (tenant_id = '') and the 3.x default namespace id (public);
• legacy beta/tag gray release migration from config_info_beta and config_info_tag to the current config_info_gray model;
• mixed-version runtime synchronization that keeps the legacy and current storage forms in sync during rolling upgrade.

For Nacos 3.3, we plan to remove this migration compatibility logic and keep only the current Config model.

After this removal, Nacos will no longer guarantee a fully smooth upgrade from versions before 3.0 when the old cluster has used the default namespace or beta gray release. If a pre-3.0 deployment has not used the default namespace and has not used beta gray release, the upgrade can still remain smooth for this compatibility area.

Target Behavior

• The current Config namespace behavior remains: blank or omitted namespace input is normalized to the default namespace id, currently public.
• The current gray release model remains: beta and tag gray releases are represented by config_info_gray and GrayRule.
• Nacos 3.3 no longer auto-migrates or double-writes data between tenant_id = '' and tenant_id = 'public'.
• Nacos 3.3 no longer auto-migrates or double-writes legacy beta/tag rows in config_info_beta and config_info_tag.
• Operators upgrading from pre-3.0 versions must handle legacy default-namespace and beta/tag data before upgrading to 3.3.

Landing Plan / TODO

Specs

• Update specs/{en,zh-cn}/design/compatibility-deprecation-spec.md to mark Config namespace storage migration and beta/tag gray migration as removed in 3.3.
• Update specs/{en,zh-cn}/config/config-gray-release-spec.md to remove the beta/tag old-table migration description and state that current beta/tag gray variants are stored in config_info_gray.
• Update specs/{en,zh-cn}/config/config-consistency-dump-visibility-spec.md to remove mixed-version beta/tag translation and namespace storage synchronization requirements.
• Update specs/{en,zh-cn}/config/config-resource-spec.md to clarify that blank namespace request normalization to public remains, but storage duplication between empty tenant and public is removed.
• Update specs/{en,zh-cn}/plugin/default-datasource-dialect-plugin-spec.md and datasource-dialect-plugin-spec.md to remove Config migration mapper requirements and legacy beta/tag table requirements from the current model.
• Update specs/{en,zh-cn}/grpc-api/api-spec.md if ConfigChangeClusterSyncRequest compatibility fields (isBeta, tag) are no longer used by server-side mixed-version migration.

Server Code

• Remove ConfigMigrateService as a service-level migration entry point.
• Remove ConfigCompatibleConfig and the nacos.config.namespace.compatible.mode configuration key if no other code path still needs it.
• Remove nacos.config.gray.compatible.model, nacos.namespace.migrate.retry.times, and nacos.namespace.migrate.batch.size.
• Remove migration calls and dependencies from ConfigOperationService.
• Remove migration calls and old-table dependencies from ConfigControllerV3, including the config_info_beta existence check and ConfigInfoBetaPersistService usage.
• Remove migration calls and ConfigMigrateService dependency from ConfigChangeClusterSyncRequestHandler; keep only current config change dump handling.
• Remove migration state checks from DumpChangeConfigWorker and DumpChangeGrayConfigWorker.
• Remove ConfigRequestInfo.namespaceTransferred if it remains write-only after migration removal.
• Remove PropertyUtil.GRAY_MIGRATE_FLAG and related history-suppression branches if they are only used by the removed migration task.

Persistence And Datasource Plugins

• Remove ConfigMigratePersistService and embedded/external implementations.
• Remove ConfigMigrateMapper and all default datasource implementations: MySQL, PostgreSQL, Derby, and Oracle.
• Remove ConfigInfoBetaPersistService / ConfigInfoTagPersistService and embedded/external implementations if no current beta/tag gray path still uses old tables.
• Remove ConfigInfoBetaMapper / ConfigInfoTagMapper and default datasource implementations if old-table persistence is fully removed.
• Remove mapper SPI registrations for Config migration and legacy beta/tag mappers.
• Remove current fresh-install schema definitions for config_info_beta and config_info_tag if the old tables are no longer part of the 3.3 schema.
• Review PostgreSQL null-tenant upgrade scripts and schema defaults to ensure they do not imply automatic empty-tenant to public migration in 3.3.
• Keep historical upgrade SQL files only when they are still needed for older upgrade paths; document that they are not an automatic 3.3 migration substitute.

Tests

• Delete or rewrite ConfigMigrateServiceTest.
• Delete embedded/external ConfigMigratePersistService tests.
• Delete default datasource ConfigMigrateMapper tests.
• Delete or rewrite old ConfigInfoBetaPersistService / ConfigInfoTagPersistService tests if the old persistence services are removed.
• Update ConfigOperationServiceTest, ConfigControllerV3Test, ConfigChangeClusterSyncRequestHandlerTest, dump worker tests, and datasource mapper coverage tests.
• Keep tests for current beta/tag gray behavior through config_info_gray.
• Add or keep tests that blank namespace requests are normalized to public without creating an empty-tenant duplicate.
• Update test/openapi-test/*_API_TEST_SCENARIOS.md, API_TEST_COVERAGE.md, and maintainer SDK scenario docs if beta/tag compatibility wording changes.

Documentation And Release Notes

• Add a 3.3 upgrade note explaining that fully smooth upgrade from pre-3.0 is no longer guaranteed when the old deployment used the default namespace or beta gray release.
• Document the safe smooth-upgrade condition: pre-3.0 deployments that did not use the default namespace and did not use beta gray release are not affected by this compatibility removal.
• Document the required operator action for affected deployments: migrate default-namespace data from empty tenant to public, and migrate beta/tag gray data to config_info_gray, before upgrading to 3.3.
• Mention the removal in the 3.3 release notes and migration guide.

Notes

This issue only tracks removal of Config migration compatibility logic. It does not remove the current default namespace semantics, current config_info_gray gray release capability, or current beta/tag gray API behavior that is backed by the gray model.