[type:refactor] externalize Aliyun SLS logging to plugin-store - #7501

Review: externalize Aliyun SLS logging to plugin-store

Thanks for the thorough migration work. I verified the code, cross-dialect schema consistency, residual references, and CI.

What is done correctly

• Cross-dialect schema consistency (the part that usually breaks). The Aliyun SLS plugin (id='34') is removed from plugin, plugin_handle, namespace_plugin_rel, and the resource (menu + 8 permission rows) tables in all five production dialects (mysql/ob/og/oracle/pg). The plugin_handle deletion is consistent: 18 rows per dialect (14 base fields + 3 mask fields + 1 sampleRate). The H2 admin schema (shenyu-admin/src/main/resources/sql-script/h2/schema.sql) also deletes exactly 18 plugin_handle rows for '34', matching every other dialect. This is the exact spot where a sibling PR (#7500) previously left 5 orphan rows, so I checked it deliberately and it is clean here.
• PluginEnum.LOGGING_ALIYUN_SLS(175, 0, "loggingAliyunSls") is retained as a stable compatibility contract. Good — this preserves the name/sort for store metadata, persisted configuration, and any external code, and avoids breaking the public enum surface in shenyu-common.
• Residual references are fully clean. A full-tree scan of the PR head for aliyun/AliyunSls (excluding the unrelated TencentClsSlsLogCollector, where "Sls" = ShenYu Logging Service) finds no remaining file referencing the removed package, the artifactId shenyu-spring-boot-starter-plugin-logging-aliyun-sls, or any deleted class. The only symbol usages of LOGGING_ALIYUN_SLS outside the deleted module are the two enum definitions themselves, so removing the e2e Plugin.LOGGING_ALIYUN_SLS entry leaves no dangling compile reference.
• Version property removed safely. aliyun-log-producer.version (root pom.xml) and the aliyun-log / aliyun-log-producer LICENSE entries are removed; the only consumer was the deleted module, so no kept pom.xml now references an undefined property.
• Module wiring removed from shenyu-plugin/shenyu-plugin-logging/pom.xml and shenyu-spring-boot-starter-plugin/pom.xml, and the bootstrap dependency is dropped.
• CI is fully green across the board (build, all integrated-test/k8s/e2e suites, CodeQL, native-sql, build-docker-images).

Non-blocking suggestions

1. RELEASE-NOTES entry. Since the plugin module moves out of core, please add a ## Unreleased → ### Behavior Changes line in RELEASE-NOTES.md stating that loggingAliyunSls is now delivered via shenyu-plugin-store (with PluginEnum.LOGGING_ALIYUN_SLS retained for compatibility). This is the only early signal downstream custom-deployment authors get.
2. Doc source. docs/cloud-logging-pluginenum-compatibility.md is created by renaming the module's META-INF/spring.factories. Functionally correct (the real autoconfig is removed via the deleted META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports), but it would read cleaner to delete spring.factories and author the doc from scratch rather than repurposing a license-header file.
3. Body vs state. The PR body still says "This PR remains draft" and lists cutover gates, but the PR is open (not draft) and CI has passed. Please sync the description: merge should be coordinated with the store release (shenyu-plugin-store#11) and its published artifacts, which is a release-process gate rather than a code issue.

Conclusion

The code is correct and ready. Approved. The only thing to sequence is the store-side publication before the actual merge, per the cutover plan — that is outside this code review.