refactor: verify client CONNECT state machine and error propagation with standard RFC 9110 server

[ssharkkky]

背景与根因关联

在与 forwardproxy 配套使用时，客户端在访问双栈目标（如 CDN 托管站点、模型 API 等）时，偶发遭遇上层连接超时（如 10 秒卡死）或 ECONNRESET。

经排查，该问题为原版 Naive 架构在客户端与服务端之间的时序协同缺陷：

1. 服务端提前回送 200 OK（Fast Open）与客户端握手时序冲突：
   • 客户端在 src/net/quic/quic_proxy_client_socket.cc 中处理 CONNECT 响应；
   • 原版设计中客户端收到提前 200 OK 即向应用层声明连接完成，应用层立即发出 TLS ClientHello；
   • 但此时服务端可能正处于目标多 IP 的串行阻塞拨号中，一旦出现单栈卡死或最终失败，客户端只能在被动超时或连接重置之间摇摆。

---

协同修复与适配规划

配合服务端 forwardproxy 纠正 RFC 9110 / RFC 8305 规范时序，客户端侧需完成以下适配与验证：

1. 客户端 CONNECT 状态机与错误处理审查

• 审查 src/net/quic/quic_proxy_client_socket.cc 中关于 use_fastopen_、read_headers_pending_ 以及 STATE_READ_REPLY_COMPLETE 的状态流转；
• 确保当服务端调整为“真实目标建连成功后再返回 200 OK”的标准时序时，客户端无死锁、无时序竞争，状态机平滑进入 STATE_CONNECT_COMPLETE；
• 验证当目标不可达、服务端按标准返回 502/504 响应码时，客户端能合规地将网络错误映射回上层应用，使上层应用能及时感知并进行正确的退避重试，而非挂死在 TLS 握手阶段。

2. 回归与端到端验证

• 跑通客户端所有现存的单元测试与回归套件；
• 在真实多 IP 双栈网络环境下发起高并发新建连接压力测试，验证 10s 超时与非预期 RST 彻底消除。

[ssharkkky]

补充上下文：历史提交（F1 审计项等）与架构盲区复盘

复盘近期客户端关于 Fast Open 的提交（153de92c8e net/quic: complete pending read on Fast Open async CONNECT failure 等）：

1. 此前修法的局限：

   • 此前为了解决应用层在异步失败时 Read() 无限挂起的问题，在 quic_proxy_client_socket.cc 中引入了 FailPendingReadOnFastOpenFailure，收到失败后主动 Reset 流；
   • 这虽然防止了永久死锁，但也成为了应用层频繁遭遇 ECONNRESET 的直接诱因；
   • 它把服务端当成了不可控的黑盒，误以为“异步失败是不可避免的”，试图通过在客户端单侧打补丁来掩盖时序失步。

2. 多 IP 双栈场景下的真正病因：

   • 客户端收到 200 OK 后，应用层的连接超时计时器（如 Node.js undici 的 10 秒倒计时）立即启动并发出 ClientHello；
   • 若服务端在后台遭遇双栈目标的首选 IPv6 丢包并陷入串行阻塞，客户端应用层必然在死等中撞上 10.5 秒超时；
   • 彻底解决此问题需要服务端与客户端协同恢复 RFC 9110 规范时序（真实建立目标 TCP 握手后再确认 200），彻底废弃非标的“假装连通”机制。