Implement optimized HTTP client in client workers and/or revisit HTTP/2

The client workers currently use the default HTTP client to perform discovery and signaling, and we have thus far made no effort to control the number of TCP connections created by a client during a signaling session.

A client, over the course of a signaling session, will create a series of HTTP requests, each one representing a message exchange with their signaling partner. These requests should be placed over a single long-lived TCP connection.

Related to this is the topic of HTTP/2 and signaling session parallelism: a client who wishes to quickly advertise N connection slots will create N concurrent HTTP requests. If both Freddie and the clients speak HTTP/2, these parallel requests can be very desirably muxed over a single TCP connection. We discussed HTTP/2 support while brainstorming and writing RFCs, but I'm not sure where we left it.

Start by locating the client workers and their discovery and signaling HTTP request paths, then review the existing HTTP/2 discussion and RFCs mentioned in the issue. Determine the intended connection reuse and HTTP/2 parallelism behavior, and confirm completion with focused tests or measurements showing the signaling session uses the agreed connection model.