Add more details about why the handshake is aborted in the HTTP
response.

Refs: #2045 (comment)

Close the connection if the Upgrade header field in the HTTP response
contains a value that is not an ASCII case-insensitive match for the
value "websocket".

Make some server error messages consistent with the respective client
error messages.

Drop the `Authorization` and `Cookie` headers if the original request
for the opening handshake is sent over HTTPS and the client is
redirected to the same host over plain HTTP (wss: to ws:).

If an HTTPS server redirects to same host over plain HTTP, the problem
is on the server, but handling this condition is not hard and reduces
the risk of leaking credentials due to MITM issues.

Refs: 6946f5fe

Add the ability to inspect the invalid handshake requests and respond
to them with a custom HTTP response.

Closes #2045

When set to non empty values, the `WS_NO_BUFFER_UTIL` and
`WS_NO_UTF_8_VALIDATE` environment variables, prevent the optional
`bufferutil` and `utf-8-validate` dependencies  from being required,
respectively.

These might be useful to enhance security in systems where a user can
put a package in the package search path of an application of another
user, due to how the Node.js resolver algorithm works.

Ensure that the `Connection`, `Sec-WebSocket-Key`,
`Sec-WebSocket-Version`, and `Upgrade` headers are not overridden.

Refs: #2048 (comment)

Drop the `Authorization` and `Cookie` headers if the original request
for the opening handshake is sent to an IPC server and the client is
redirected to a TCP server (ws+unix: to ws: or wss:), and vice versa
(ws: or wss: to ws+unix).

Also drop the `Authorization` and `Cookie` headers if the original
request for the opening handshake is sent to an IPC server and the
client is redirected to another IPC server.

Refs: 6946f5fe