etcdserver: v3.7 组长以倒序日志顺序向对等节点发送 MsgApp

与安全性无关。不是支持请求。没有现有报告此发送命令错误。### 发生了什么？在 v3.7.0、v3.7.1 和主版本中，`processMessages` 以最后到第一的顺序遍历 Ready 消息，并附加保留的消息，因此 `MsgApp` 以倒序日志顺序离开领导者。v3.6 返回原始切片。跟随者拒绝在依赖的索引之前到达的 `MsgApp`。领导者降低 `Next` 并重新发送。这些拒绝不是 rafthttp 发送失败。由 f3cea0a978 (#21810) 引入，保留在 4715a5474c (#21778) 中。raft 仍然以日志顺序发出 `Ready.Messages`。### 您期望发生什么？幸存者以 Ready 顺序离开。保留后向滤镜（删除的成员，更旧的 `MsgAppResp`、`MsgSnap`）。不要在输入上设置 `To = 0`；它们是指向 raft 状态的指针。请将此功能回移植到 release-3.7。v3.6 不受影响。### 如何重现此问题（尽可能简洁和精确）？调用 `processMessages` 与 `TestProcessDuplicatedAppRespMessage` 相同：1. 发送给对端 2 的 `MsgApp`，索引为 10、11、122. 发送给对端 1 的 `MsgAppResp`，索引为 1 然后为 23. 发送给已删除对端 5 的 `MsgApp`在主版本中，保留的消息以倒序返回（`MsgApp` 12、11、10，然后是 `MsgAppResp` 2）。预期值：`MsgApp` 10、11、12，然后是 `MsgAppResp` 2。输入保持不变。https://GitHub.com/etcd-io/etcd/blob/main/server/etcdserver/raft.go#L357-L401### 需要了解的其他信息？在持续写入的集群中，赶上时间的跟随者接收每个条目大约 2.5 到 3 次。一个较慢成员的重新发送填充了 4096 位置的 rafthttp 发送缓冲区（“发送缓冲区已满”）。集群保持运行，但客户端看到高延迟、失败的提案、跟随者滞后和快照。在相同工作负载上，v3.6.13 则不如此。在具有 12 KB 值的 5 个成员的集群中，v3.7.1 持续的放置速率约为 v3.6.13 的一半。恢复发送顺序与 v3.6.13 相匹配。### Etcd 版本main、v3.7.0 和 v3.7.1。上述顺序检查是重现。### Etcd 配置N/A### Etcd 调试信息N/A### 相关日志输出N/A