[ENHANCEMENT]: 心跳&配置同步逻辑优化

[PapaPiya]

Concisely describe the proposed feature

当config server接入海量实例后，会对服务端压力会较大，主要是因为每次心跳请求都会做一次配置同步。期望能够对当前心跳&配置同步逻辑进行优化。

Describe the solution you'd like (if any)

1. 注册请求：agent_type,attributes,startup_time,pipeline_configs等固定信息都可以在启动后通过注册请求上报，减少心跳携带数据量。
2. Config同步逻辑统一到Command中：配置同步操作可以由服务端在心跳响应中通过Command传递，与其他Command逻辑保持一致。同步操作可以由页面配置改动后创建Command，Agent执行后会上报Command执行成功。

[Takuka0311]

1、当前心跳携带的数据量确实比较大，分开成“数据上报（agent_type,attributes,startup_time等）”和“拉取配置更新（pipeline_configs等参数）”两个接口可能会比较好，以“拉取配置更新”行为作为心跳。后续可以把监控和配置管理分开
2、同步配置的行为不建议修改：“同步操作可以由页面配置改动后创建Command，Agent执行后会上报Command执行成功。”这里需要在ConfigServer处管理Command，不太好处理中途iLogtail移出Agent组、或有新的Agent在Command执行成功后加入的情况。依旧是iLogtail拉取配置，能保证iLogtail最终生效的配置一定与它所在的AgentGroup一致

[liangry]

都挺好的，我有另一个需求：在心跳中增加 Agent 的资源占用，实践证明，CPU 和内存使用情况在问题分析上有重要作用

[PapaPiya]

都挺好的，我有另一个需求：在心跳中增加 Agent 的资源占用，实践证明，CPU 和内存使用情况在问题分析上有重要作用

可以通过自监控解决，相关功能应该在规划/开发中了

[Takuka0311]

都挺好的，我有另一个需求：在心跳中增加 Agent 的资源占用，实践证明，CPU 和内存使用情况在问题分析上有重要作用

可以通过自监控解决，相关功能应该在规划/开发中了

是的，ConfigServer近期是准备开始升级了。我们的开源之夏活动里，其中一个项目就是ConfigServer的升级，届时可以向负责开发的同学提需求和建议:D