🐛 fix(http): bound the gap in a request body

[gaborbernat]

Nothing bounded how long a client could hold a handler. A request that stopped arriving occupied it until the connection died, and any lock that handler took stayed taken for as long. The upload path shows the cost: reclaim_idle takes each expired session's gate in turn, so one stalled PATCH blocked the reclaim of every other expired session behind it.

The edge now fails a request body that goes thirty seconds without a frame, and the wait starts again at each frame. ⏱️ The gap is the thing to bound, because a large upload over a slow link is making progress and has to finish. A total bound would have to exceed the slowest legitimate transfer, which leaves it far too loose to catch a stall, and no single value serves both an upload chunk and a multi-gigabyte layer. A gap bound needs no such split. Silence means the same thing on every route, so this stays one number in one place rather than a per-handler patchwork, and thirty seconds is the span peryx already allows an upstream it is reading from, turned around to face the sender.

It composes with the throughput floor from PR #2149 by governing a different stream on a different axis. That floor bounds bytes arriving from an upstream peryx reads; this bounds bytes arriving from a client peryx serves. Neither counts total elapsed time, so a transfer that keeps delivering trips neither. A total inbound bound would have overridden the floor outright, cutting the 2 GiB layer that floor exists to let finish.

A client sees the status the append path already answers for a body that fails mid-chunk, and the session it was filling stands at the bytes that reached disk, so it can read that offset back with a status GET, send the rest, or cancel. One wart rides along. That status is 502 carrying a message about an upstream transfer, which never fitted a client-side body failure and which a connected client can now read. Correcting it means changing how each ecosystem classifies a body error, the patchwork this issue exists to avoid, so it belongs in its own change.

Wrapping with the body tower-http ships broke every chunked upload: TimeoutBody drops the size hint that Content-Range checks against, turning each ranged chunk into a rejected one. 🔍 Six existing tests caught it. The wrapper here forwards that hint, which is why it exists rather than coming from the crate.

A test measures the reclaim case rather than arguing it. It stalls a PATCH on an expired session, runs a pass, and pins the delay to one stall bound instead of the client's connection lifetime, with both sessions reclaimed at the end. A client that trickles rather than stalls still evades this, the way an outbound trickle evaded the read timeout until #2149 added a floor on top of it, and that case wants the same second bound and an issue of its own.

Closes #2176

[codspeed-hq]

Merging this PR will not alter performance

✅ 29 untouched benchmarks
⏩ 133 skipped benchmarks¹

---

_{Comparing fix/inbound-request-bound-2176 (9aa9b72) with main (f239a18)}

Footnotes

1. 133 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩