fix: graceful TCP close to stop RST on early error responses (#185)

[bushidocodes]

Closes #185

Summary

Fixes the root cause behind #185 — hey logging Unsolicited response received on idle HTTP channel starting with "HTTP/1.1 503 ...".

SLEdge often answers a request before it has finished reading it: the short-circuit error responses (400/404/429/500/503) in the listener thread write the response and close() the socket while the client may still be sending its request body. tcp_session_close() did a bare close(), and on Linux a close() with unread data in the kernel receive buffer discards it and emits a TCP RST instead of a graceful FIN. The client surfaces that RST as connection reset by peer or, on a pooled keepalive connection, as the exact Unsolicited response received on idle HTTP channel warning in the issue. This matches the maintainers' own hypothesis in the issue thread ("we write a response before reading the entire HTTP request").

Change

tcp_session_close() now closes gracefully:

1. shutdown(SHUT_WR) — send our FIN so the client (now holding a complete response) stops sending.
2. Drain already-buffered inbound data with a non-blocking, bounded loop (32 × 8 KiB) so close() never sees unread data, while guaranteeing the single listener thread can't block or spin on a slow/malicious client.

One file, +41 lines, no change to the success path.

Verification

Reproduced and verified in the Docker dev environment with hey:

Case	Before	After
Normal 200 traffic (5000 req)	200×5000, ~15k rps	unchanged, 0 warnings
GET → 429/503 (originally reported scenario)	already clean	clean
POST 100 KB body → 404 route (connection reset by peer)	~159 / 2400 req	0

Note: the originally reported bodyless-GET scenario is already clean on current master (admissions/scheduler 429s now fire after the full request is read). The reproducible residual was a request with a body hitting an early-error route, which this fixes.

Known limitation

A client that keeps streaming a large body to a rejected route may still observe its own write abort as broken pipe (EPIPE). Fully suppressing that would require lingering on the request in the event loop (a draining state in the listener), which is disproportionate for this log-level issue — left out of scope and documented in the code comment.

🤖 Generated with Claude Code

[emil916]

I've never run into this issue. The server doesn't send any of the mentioned error responses (400/404/429/500/503), unless the request is fully received, no? I don't see how this is ever useful.

[emil916]

I see. I remember now, I used to get these 503 errors back in 2022 when using hey (now I am pretty much using my own loadtest).