rproxy: answer a visitor that stops sending its body after the app has answered (closes #298)

When the app answered before the visitor's body had arrived whole, Go's
server read up to 256 KiB of the rest before it sent the answer. A
visitor that stopped sending got nothing until SWRP_MAX_REQUEST_TIME_MS
ran out, and no bytes at all once that was past the 10 seconds the
status has to be sent.

Such an answer now carries Connection: close, which Go sends at once.
finish first ends the transport's read of the body: once the handler
returns, Go's server reads the rest with no deadline while another read
of it waits. requestBody.Close does nothing, so that ReverseProxy's
close does not wait on the visitor.

Model: opus-5-5

SPEC.md

@@ -2304,8 +2304,14 @@ no report. Its log line has status `0` and no `disposition`.
 
 `rproxy` sends the app at `SWRP_UPSTREAM_URL` the visitor's request: the part of
 the body it holds, then the rest, streaming. The app's answer comes back the
-same way. Apart from what Go's HTTP code changes, the request reaches the app
-unchanged but for these headers:
+same way.
+
+An app may answer before the visitor has sent its whole body. The visitor gets
+that answer at once, and the connection closes after it. Once the answer is
+complete, the rest of the body no longer goes to the app.
+
+Apart from what Go's HTTP code changes, the request reaches the app unchanged
+but for these headers:
 
 - `X-Forwarded-For`, with the address of `rproxy`'s TCP peer added, when that
   peer is inside `SWRP_TRUSTED_PROXIES`. The peer's other forwarded headers pass