* feat(tcp): implement window scaling (RFC 7323)
The window-scale option was parsed for length validation but never applied:
the effective receive window was capped at the 16-bit field, which caps
throughput at 65535/RTT (about 4MB/s on a 15ms path) no matter how large the
receive buffer is. Worse, a receive buffer over 64KiB silently WRAPPED the
advertised window on the SYN (uint16 truncation): a 128KiB buffer went on
the wire as a near-zero window.
Design: scaling lives purely at the wire seam in Handler. The ControlBlock
always holds real octet counts; conversion happens on frame read (peer
windows shifted up by the peer's offer, never on SYN segments) and frame
write (wireWnd: our shift down, SYN never scaled, saturation instead of
wrap when the value still does not fit). The local shift derives from the
receive buffer size in SetBuffers; every active SYN offers it (a zero
shift still lets the peer scale, RFC 7323 §2.5) and a SYN-ACK echoes it
only when the peer's SYN carried the option. The ControlBlock's three
2**16 window caps move to the scaled maximum (65535<<14).
Tests: on-wire negotiation with asymmetric buffers (shift values, unscaled
saturated SYN windows, first scaled advertisement, peer scaling back up);
a transfer proving more than 64KiB genuinely in flight without a single
ACK, received intact; wire-safety corners (no echo without an offer,
saturation not wrap, so the pre-existing 128KiB SYN wrap bug stays pinned).
Fuzzers clean: 9.1M TCB execs, 4.9M full-stack HTTP execs, 7.2M TCB
actions.
* use min instead of if statement
* omitting use of min saves 8 bytes
* fix option offset bug and add OptionCodec.Next method
---------
Co-authored-by: Derek den Haas <d.haas@directcode.com>
* begin prepping policy refactor manually
* implement tcp.Policy and refactor rto to use it
* fix CI
* chatting with claude gave me idea to reformulate Policy
* tcp.Policy: add newTransmitLimit output
* merge with main and fix failing tests
* remove fix.patch
* answer my own comments
Pat Whittingslow