feat: RocketMQ supports Wasm parsing

[lzf575]

This PR is for:

[lzf575]

@claude review 下pr，使用中文

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[lzf575]

@claude review 下pr，使用中文

[claude]

Claude finished @lzf575's task in 6m 32s —— View job

---

进度

• 梳理 PR 上下文与仓库约束
• 审阅 RocketMQ Wasm 解析改动
• 整理中文评审意见并更新 PR 评论

评审结论

我看完这次 PR 了，整体方向没问题：在 @agent/src/flow_generator/protocol_logs/mq/rocketmq.rs 里给 RocketMQ 增加了 Wasm 自定义解析入口，并把插件返回的 request/response/trace/biz 字段合并回 RocketmqInfo。实现也基本沿用了现有协议的模式。

不过我建议先修 1 个正确性问题，再合入。

发现的问题

• 请求侧的 req_code_name 可能被响应侧插件结果错误覆盖
  位置：@agent/src/flow_generator/protocol_logs/mq/rocketmq.rs:277
  在 merge_custom_info() 里有这段逻辑：

  if !custom.resp.req_type.is_empty() {
      self.req_code_name = custom.resp.req_type;
  }

  这里把 resp.req_type 直接写回了请求类型字段 req_code_name。如果插件在响应方向返回了一个仅对响应有意义的 req_type，会把原本根据 header.get_request_code_str() 解析出来的请求类型覆盖掉，最终影响：

  • req.req_type
  • 黑名单匹配（set_is_on_blacklist() 依赖 req_code_name，见 @agent/src/flow_generator/protocol_logs/mq/rocketmq.rs:323）
  • 请求/响应合并后的最终日志语义

  这个写法虽然和 WebSphereMQ 当前逻辑类似，但对 RocketMQ 来说，req_code_name 明确承载的是请求码语义，直接接受 resp.req_type 覆盖风险较高。

  建议至少限制为：仅在当前值为空时再回填，或者更稳妥地只接受 custom.req.req_type 来改写该字段。
  Fix this →

其他观察

• wasm_hook() 的接入位置在 parse_payload() 里、黑名单判断之前：@agent/src/flow_generator/protocol_logs/mq/rocketmq.rs:427-430。这个时序是合理的，插件补充的 endpoint / group / topic 能参与后续黑名单判断。
• 当前 RocketMQ 已有 pcap 回归测试：@agent/src/flow_generator/protocol_logs/mq/rocketmq.rs:1936，但看起来没有覆盖 Wasm 分支。如果你准备继续扩展插件字段，建议补一个针对 merge_custom_info() 或 Wasm hook 的定向测试，后面更不容易回归。

总结

结论是：有一个建议修复的正确性问题，其余整体 OK。修掉 req_code_name 的覆盖逻辑后，这个 PR 会更稳。