ConfigChangeAspect may misclassify console config changes as RPC when srcType is missing

[Hccake]

Describe the bug
EN:

ConfigChangeAspect determines the config change pointcut type from ConfigRequestInfo.srcType.
Currently, when srcType is missing or empty, the change may be classified as an RPC change
instead of reflecting that the caller did not provide a source.

Some upstream config publish entries, especially console/admin HTTP paths, may construct
ConfigRequestInfo without explicitly setting srcType. In this case, a config change triggered
from the console UI can be incorrectly treated as an RPC change by the config change aspect.

This becomes observable with external config-change plugins. For example, the file-format config
change plugin in nacos-plugin skips RPC-type change handling:
https://github.com/nacos-group/nacos-plugin/blob/develop/nacos-config-change-plugin-ext/nacos-fileformat-config-change-plugin/src/main/java/com/alibaba/nacos/plugin/config/FileFormatConfigChangePluginService.java

Because the console-originated change is incorrectly marked as RPC, invalid config content that
should be intercepted by the plugin may bypass validation.

ZH:

ConfigChangeAspect 会根据 ConfigRequestInfo.srcType 判断配置变更的切点类型。
目前当 srcType 缺失或为空时，变更可能会被归类为 RPC 变更，而不是保留真实入口来源，
或者体现调用方没有提供来源这一事实。

部分上游配置发布入口，尤其是控制台或 admin HTTP 路径，可能会构造一个没有显式设置
srcType 的 ConfigRequestInfo。这种情况下，从控制台界面触发的配置变更可能会被
配置变更切面错误判断为 RPC 变更。

这个问题在外部配置变更插件中会产生实际影响。例如 nacos-plugin 中的文件格式校验
配置变更插件会跳过 RPC 类型的变更处理：
https://github.com/nacos-group/nacos-plugin/blob/develop/nacos-config-change-plugin-ext/nacos-fileformat-config-change-plugin/src/main/java/com/alibaba/nacos/plugin/config/FileFormatConfigChangePluginService.java

由于控制台来源的变更被错误标记为 RPC，原本应该被插件拦截的错误配置内容可能无法被
正常拦截。

Expected behavior

EN:

Config changes should be routed to the correct config-change pointcut according to their real
entry source:

• HTTP or console/admin HTTP entries should be classified as HTTP changes.
• RPC entries should be classified as RPC changes.
• Missing, empty, or currently unclassifiable srcType values should not be silently treated as
  RPC.
• Delete operations should use remove pointcuts instead of publish pointcuts.

With this behavior, console config changes can still be processed by plugins that intentionally
skip RPC events.

ZH:

配置变更应该根据真实入口来源路由到正确的配置变更切点：

• HTTP 或控制台/admin HTTP 入口应该被识别为 HTTP 变更。
• RPC 入口应该被识别为 RPC 变更。
• 缺失、为空，或者当前无法明确分类的 srcType 不应该被静默当作 RPC 处理。
• 删除操作应该使用 remove 切点，而不是 publish 切点。

这样控制台配置变更仍然可以被那些有意跳过 RPC 事件的插件正常处理。

Actually behavior
EN:

When ConfigRequestInfo.srcType is not explicitly set by an upstream caller, the aspect may treat
the change as RPC. This changes the observable pointcut type passed to config-change plugins.

For the file-format config change plugin mentioned above, RPC-type changes are skipped. Therefore,
a console-originated config publish operation can be misclassified as RPC and bypass plugin
validation.

In addition, delete operations may be routed through publish pointcuts instead of remove pointcuts,
which is inconsistent with the existing pointcut model.

ZH:

当上游调用方没有显式设置 ConfigRequestInfo.srcType 时，切面可能会把该变更当作 RPC
处理。这会改变传递给配置变更插件的实际切点类型。

对于上面提到的文件格式校验配置变更插件，RPC 类型的变更会被跳过。因此，一个从控制台
发起的配置发布操作可能因为被错误识别为 RPC 而绕过插件校验。

另外，删除操作也可能会走 publish 切点，而不是 remove 切点，这与现有切点模型不一致。

How to Reproduce
EN:

1. Enable or use a config-change plugin that treats HTTP and RPC pointcuts differently, for example
   the file-format config change plugin from nacos-plugin.
2. Configure the plugin so that invalid config content should be rejected for console or HTTP config
   publish operations.
3. Publish or update an invalid config from the Nacos console UI or an admin HTTP entry where
   ConfigRequestInfo.srcType is not explicitly set.
4. Observe that the config change can be classified as RPC.
5. Because the plugin skips RPC-type changes, the invalid config may not be intercepted.
6. For delete operations, observe that remove-specific pointcuts may not be used.

ZH:

1. 启用或使用一个会区分 HTTP 与 RPC 切点的配置变更插件，例如 nacos-plugin 中的文件
   格式校验配置变更插件。
2. 配置该插件，使控制台或 HTTP 配置发布操作中的错误配置内容应该被拒绝。
3. 从 Nacos 控制台界面，或者某个没有显式设置 ConfigRequestInfo.srcType 的 admin
   HTTP 入口发布或更新一份错误配置。
4. 观察该配置变更可能会被识别为 RPC。
5. 由于插件跳过 RPC 类型变更，错误配置可能不会被正常拦截。
6. 对于删除操作，可以观察 remove 专用切点可能没有被使用。

Desktop (please complete the following information):

• OS: Windows / Linux
• Version: Nacos develop branch, observed around 3.2.1-SNAPSHOT
• Module: config, console, plugin/config, ai
• SDK: original / console UI / HTTP API

Additional context

[Hccake]

/assign

[github-actions]

@Hccake has been assigned to this issue / 已被分配到此 Issue.

[KomachiSion]

@Hccake 能否先把方案在issue中讨论一下，再进行PR，避免因为方案理解不同问题导致的无效变更。

[Hccake]

@Hccake 能否先把方案在issue中讨论一下，再进行PR，避免因为方案理解不同问题导致的无效变更。

ok。目前主要是 ConfigChangeAspect 切面中对于 ConfigChangePointCutTypes 的判断逻辑有问题，非 HTTP 类型的 scrType 就会被设置为 RPC，但是很多上游配置操作的地方并没有设置 scrType，例如控制台的配置操作。这导致即使引入了配置变更插件，在控制台进行错误的配置发布时，依然可以成功。

同时目前对于删除操作赋值的 ConfigChangePointCutTypes 是 PUBLISH_BY_XX 而不是已经定义的枚举 REMOVE_BY_XX，如果下游插件需要根据类型做具体操作时无法区分。

改动方案：

1. 新增 ConfigChangePointCutTypes ：PUBLISH_BY_UNKNOWN 和 REMOVE_BY_UNKNOWN，在无 scrType 归类到此类型，防止错误的类型判断
2. 修正删除操作的类型赋值，切换到 REMOVE_BY_XX
3. 为 console 的 http 入口处赋值 scrType 为 HTTP

[KomachiSion]

1. 可以作为兜底属性，同时可以打印日志，unknown是从哪个api或者request来的（如果能获取到的话）。
2. 只靠上游传入这个值其实有比较大的局限性，现在有好多地方都会使用publish和remove， 是不是能从RequestContext中分析出来会比较准确？RequestContext中有getBasicContext.getRequestProtocol, 这个值应该会在http的filter和grpc的handler前被设置。 先判断这个值是否存在且是否为http或grpc， 如果这个值不存在或者不在这两者， 回退到srcType（以保持兼容），如果还取不到再用Unkown