Enable Pre-Connection Authentication using HTTP Authentication Headers

[amydevs]

Specification

It should also be possible for TLS Verification to be done via the HTTP 1.1 Basic Authentication (via the Authentication header).

To achieve this, the VerifyCallback should be expanded to also expose the headers of the incoming request:

type TLSVerifyCallback = (
  certs: Array<Uint8Array>,
  ca: Array<Uint8Array>,
  headers: IncomingHttpHeaders
) => PromiseLike<void>;

As the callers of the TLSVerifyCallbacks always have context of the IncomingMessage http request, we can pass the IncomingMessage.headers into the verifyCallback as the third param.

There will also need to be some API in the WebSocketConfig to be able to set headers for outgoing messages.

ws provides different APIs for setting headers for clients and servers:

• servers use the headers event on WebSocketServer to modify the headers before they are sent
• clients use the finishRequest callback to customize headers on the OutgoingMessage before it is sent

Additional context

• Encapsulate WebSocketClient in PolykeyClient Polykey#582 (comment)
• https://github.com/websockets/ws/blob/master/doc/ws.md#event-headers

Tasks

1. Expand TLSVerifyCallback to support passing of headers
2. Allow user to provide headers in WebSocketConfig
3. Pass provided headers to ws library

[CMCDragonkai]

I guess we would use server headers to set the session token if the connection authentication succeeded.

But this would be separate from rpc request. We also need to figure out what would happen for both RPC auth and connection auth?

I wonder if PK switches to connection auth, the RPC auth is redundant. We need to explore this architectural change.

[CMCDragonkai]

RPC auth and transport-level auth is 2 different levels of auth.

I think PK can swap to using transport-level auth for client service, while agent service is already MTLS and "public" anyway.

This actually means that RPC auth can be removed - and made optional, we can abstract it into js-rpc.