Close connection on 5xx error to avoid leaking exchanges on slow uploads

[samberic]

When a target failed before sending a response (target died or timed out), murp set a 500/504 status, wrote the body, and called asyncHandle.complete(). If the client was still uploading the request body at that point (e.g. a slow or large PUT), the request stayed in RECEIVING_BODY and never reached an end state.

MuServer only ends an exchange once BOTH the request and response are in an end state, so the exchange stayed IN_PROGRESS and the request lingered in stats().activeRequests() until the client finished uploading - which for long-running uploads could be hours or days. We observed many such PUTs stuck for days.

Setting "Connection: close" on the error response makes MuServer's HttpServerKeepAliveHandler close the channel once the response is sent. That triggers onConnectionEnded -> request.onCancelled(CLIENT_DISCONNECTED), moving the request to ERRORED so the exchange completes and is released. This mirrors what MuServer itself does for unrecoverable HTTP/1.1 errors in HttpExchange.onException.

The sibling branch (target dies after the response has started streaming) already calls asyncHandle.complete(throwable), which routes through onException and cancels the request, so it does not leak and needs no change.

[danielflower]

Inspired by the insight of this pull request, a separate fix has been made that properly consumes and discards client request bodies when the target request has a transport failure, such that the client can have a valid http 502 response. Using version 1.2.x or later.