Support smux protocol v2 for flow-controlled port forwarding

[alexbacchin]

Summary

Multiplexed port forwarding (AWS-StartPortForwardingSession) uses smux over the WebSocket data channel. Both session-manager-plugin and the SSM Agent currently negotiate smux protocol v1, which has no per-stream flow control. This means client tools have no signal for when the agent's receive/session-wide throughput cap (~500 kbps, see aws/amazon-ssm-agent#664) is being exceeded, other than the session stalling or being torn down mid-transfer.

smux v2 (supported by the xtaci/smux library already vendored here, via smux.Config{Version: 2}) adds a cmdUPD frame that acknowledges consumed bytes and advertises a receive window per stream. This would let clients pace writes based on real backpressure from the agent instead of guessing a fixed rate.

Current behavior

• muxportforwarding.go constructs its smux session with smux.DefaultConfig() and only ever overrides KeepAliveDisabled; Version is left at the library default (1).
• The client→agent bridge loop paces itself with an unconditional time.Sleep(time.Millisecond) after every read/send cycle (transferDataToServer), which caps aggregate throughput to a fixed, non-configurable rate rather than reacting to actual buffer state.
• Downstream client implementations that also multiplex over smux (e.g. third-party SSM clients) have to replicate this same fixed-rate workaround, since there's no protocol-level backpressure signal to build on.

Request

Consider negotiating smux v2 between session-manager-plugin/SSM Agent and connecting clients (with a version-negotiation or agent-version-gated fallback to v1 for compatibility), so that port-forwarding throughput can be governed by real flow control instead of a fixed sleep-based cap.

Related

• 0.6 MB/s speeds on 5 GB/s burstable instance amazon-ssm-agent#664 — confirms the ~500 kbps-class throughput ceiling and that it's enforced service-side via a message-rate cap, independent of instance size.