[3.3] Adapt external plugins to the unified plugin management model

Is your feature request related to a problem?

The server plugin lifecycle and configuration model were unified for Nacos 3.3 under #15475. The maintained external implementations in nacos-group/nacos-plugin still target Nacos 3.2.2 and some of them use compatibility APIs or SPIs that have already been replaced.

Keeping these implementations unchanged has two problems:

1. Configurable plugins cannot be managed consistently through the Nacos plugin APIs and the Next console.
2. Some compatibility paths are scheduled for removal: the legacy MCP import path in 3.4.0 and the remaining plugin configuration bridges in 4.0.0.

This issue tracks the cross-repository migration and provides independently claimable plugin-family tasks for community contributors.

Describe the solution you'd like

Update nacos-group/nacos-plugin to the Nacos 3.3 plugin contracts and verify each external implementation against a 3.3 server.

Common acceptance criteria

• Update the managed Nacos dependency from 3.2.2 to the compatible 3.3 version.
• Preserve each implementation's stable plugin type and plugin name.
• For a plugin with real configuration:
  • declare the complete ConfigItemDefinition list;
  • use canonical keys in the form nacos.plugin.{pluginType}.{pluginName}.{itemKey};
  • retain an old key only as an explicit alias when migration compatibility is required;
  • classify every item as RUNTIME or RESTART;
  • accept the effective item-key map through applyConfig and keep an immutable or safely published current snapshot;
  • stop reading EnvUtil, system properties, or deprecated compatibility configuration holders during domain execution.
• For a genuinely zero-config implementation, keep an empty definition list and isConfigurable() == false; do not invent metadata only to satisfy the new interface.
• Keep enablement and execution routing under the unified plugin state. Do not add a second implementation-local enabled gate.
• Add focused unit tests and at least one package/startup compatibility test with a Nacos 3.3 server. Configurable implementations should also verify that plugin detail exposes their definitions/effective values and that supported runtime updates reach domain execution.
• Follow first-wins identity semantics and avoid duplicate plugin IDs.

Plugin-family checklist

• Config Change
  • Migrate webhook (webhookUrl, contentMaxCapacity) and whitelist (suffixs, with a clearer canonical item key if practical) away from the deprecated ConfigChangeConfigs/legacy PLUGIN_PROPERTIES bridge. ConfigChangeConstants.PLUGIN_PROPERTIES may still be consumed from each request after migration because the 3.3 contract fills it from the plugin's accepted getCurrentConfig() snapshot.
  • Keep fileformatcheck zero-config unless a real configurable value is introduced.
  • Verify execution order, pointcuts, state disable/enable, and the configured callback/filter behavior.
• Custom Environment
  • Verify NacosDbEncryptPluginService with the PRE_CONTEXT lifecycle.
  • It is currently zero-config, so it should remain non-configurable unless a real restart-only setting is added.
  • Verify that the transformed database password is available before Spring context refresh and that the old manual join(...) path is not required.
• AI Resource Import
  • The old AiResourceImportSourceProvider model was removed.
  • skills-sh is now built into the Nacos server with the same managed source identity. Prefer retiring the external duplicate. If the external module is retained, it must use the new builder-as-PluginConfigSpec contract and must not register a duplicate plugin ID.
• Datasource Dialects
  • Verify DM, Kingbase, SQL Server, OceanBase, OpenGauss, Oracle, XuguDB, and YasDB dialects with the 3.3 SPI/provider discovery path.
  • These implementations are currently zero-config; keep them that way and focus on build, discovery, selected-dialect startup, schema, and mapper compatibility tests.
• Encryption
  • Verify the AES implementation with unified discovery and plugin state.
  • Keep it zero-config unless the implementation begins to own real settings.
• Trace
  • Verify the logging subscriber with unified discovery, first-wins identity, state disable/enable, and event delivery.
  • Keep it zero-config.

Each checkbox may be completed in a separate pull request to nacos-group/nacos-plugin. Please link that pull request back to this tracking issue so contributors can coordinate without overlapping work.

Describe alternatives you've considered

The Nacos main repository retains compatibility defaults for old zero-config binary plugins during the 3.x line. Relying only on those defaults would keep some jars loadable, but it would leave configurable implementations outside the unified lifecycle and postpone failures until the compatibility bridges are removed.

Moving all external implementations into the main repository was also considered undesirable. The main repository should own the SPI and lifecycle contract, while the external repository remains the home for optional implementations.

Additional context

Relevant work:

• #15475: parent plugin-management refactor
• #15555: plugin SPI and PluginConfigSpec unification
• #15572: Control special lifecycle integration
• #15589: AI Resource Import builder/configuration refactor
• #15590: PRE_CONTEXT Environment initialization
• #15614: deprecation markers and planned removal versions

The current plugin contract is documented under specs/en/plugin and specs/zh-cn/plugin in the Nacos repository.