[FEATURE] Add cleanup and update policy for application-level metadata / 为应用级 metadata 增加清理和更新策略

[Alanxtl]

上下文请参考 #3188 (comment)

Background

After #2534, metadata center usage in dubbo-go is centered on application-level metadata and service-app mapping. This issue does not propose restoring service-level provider/consumer metadata. It focuses on how application-level metadata should be updated and cleaned up in metadata centers.

Related code:

• metadata/report/nacos/report.go
• metadata/report/zookeeper/report.go
• metadata/report/etcd/report.go
• registry/servicediscovery/service_discovery_registry.go

Current Problems

Application-level metadata currently lacks clear update and cleanup semantics in metadata centers.

Specific problems:

• App metadata is published by revision, but there is no unpublish or cleanup strategy.
• Old revision data may accumulate indefinitely.
• Zookeeper ignores existing app metadata nodes instead of updating them.
• Provider unregister does not clearly update service-app mapping content.
• If revision calculation is not precise enough, stale metadata can remain longer.

Suggestions

• Define when app metadata should be published, updated, expired, or removed.
• Provide a cleanup or retention policy for old revisions.
• Clarify and fix behavior when Zookeeper metadata nodes already exist.
• Define whether provider unregister should update service-app mapping.
• Add tests for metadata update and cleanup behavior across supported metadata reports.

背景

#2534 之后，dubbo-go 对 metadata center 的使用聚焦于应用级 metadata 和 service-app mapping。本 issue 不讨论恢复服务级 provider/consumer metadata，只关注应用级 metadata 在 metadata center 中如何更新和清理。

相关代码：

• metadata/report/nacos/report.go
• metadata/report/zookeeper/report.go
• metadata/report/etcd/report.go
• registry/servicediscovery/service_discovery_registry.go

当前问题

目前应用级 metadata 在 metadata center 中缺少清晰的更新和清理语义。

具体问题：

• app metadata 按 revision 写入后没有 unpublish 或 cleanup 策略。
• 旧 revision 数据可能长期堆积。
• Zookeeper 遇到已有 app metadata 节点时直接忽略，而不是更新。
• provider unregister 后是否更新 service-app mapping 内容并不清晰。
• 如果 revision 计算不够精确，旧 metadata 会残留更久。

建议

• 明确 app metadata 何时发布、更新、过期或删除。
• 为旧 revision 提供清理或保留策略。
• 明确并修复 Zookeeper metadata 节点已存在时的行为。
• 定义 provider unregister 是否应更新 service-app mapping。
• 为各 metadata report 支持的更新和清理行为增加测试。

[eye-gu]

我想到一个方案不知道可不可行: remote模式下应用元数据每天定时上报(添加心跳),上报完成后检测其他revision是不是超过N天,超过的再判断一下是不是当前存活节点中已没有该revision,如果没有,进行删除. 风险:会删除N天没有成功上报,并且在检测过程中恰好启动并上报的revision,几率很小. 如果方案可行,可以指给我