End proxied responses for 1xx, 204, 304 with no body, fix bug where cy server could be proxied

[flotwig]

Fixes #4298
Fixes #4410

https://tools.ietf.org/html/rfc7230#section-3.3.3

Any response to a HEAD request and any response with a 1xx
(Informational), 204 (No Content), or 304 (Not Modified) status
code is always terminated by the first empty line after the
header fields, regardless of the header fields present in the
message, and thus cannot contain a message body.

This PR short-circuits the proxy's response in these cases to just end the response. This prevents the kind of lagging behavior seen in #4298.

---

This PR also fixes a bug where the server's websocket port could be proxied if NO_PROXY == ''.

[brian-mann]

@flotwig can you leave your comments here regarding the pairing with did and the followup work involved with understanding why keepAlive: true causes the 5 second delay when running from within cypress?

[brian-mann]

Approving this but more investigation needs to be done as to why keepAlive: true is causing the 5 second delay (likely due to server.keepAliveTimeout being set to 5000ms by default)

[flotwig]

@flotwig can you leave your comments here regarding the pairing with did and the followup work involved with understanding why keepAlive: true causes the 5 second delay when running from within cypress?

We noticed there was an exact 5 second delay while loading the 304. We don't have any 5 second timeouts in our codebase, but 5 seconds is the default Node httpServer.keepAliveTimeout value: https://devdocs.io/node/http#http_server_keepalivetimeout

Initially, we thought this came from either the https-proxy server or the server server or the e2e test server, so we set those servers' keepAliveTimeouts to numbers like 2500 or 7500 to try and see if it had an effect. It didn't.

Turning keepAlive off on the http-mitm-proxy caused the issue to stop occurring, so something is likely wrong with the way we are handling keepAlive connections.