Should we combine .host and .socketPath on HTTPClient.Request?

While refactoring the unix domain socket implementation in #228, I noticed that we could probably combine the host and (new) socketPath properties on HTTPClient.Request.

From what I could tell:

• The socket path would end up in the Host header for the request (currently it is "")
• TLS would use the socket path on certs as the common name/hostname (currently it is checking for "" as opposed to nil, which it's doing for IPs)
  • IPs are explicitly forbidden from the SNI spec. It says:

Literal IPv4 and IPv6 addresses are not permitted in "HostName".

• • The same spec does not forbid using socket paths however:

Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document). TLS MAY treat provided server names as opaque data and pass the names and types to the application.

• • However, we should still check the common name in cert validation for matching hostnames
• Responses would propagate the socket path as their host as well (currently, it's also set to "" for socket domain responses)
• We would need better test coverage for these scenarios.

Start with HTTPClient.Request and the unix domain socket implementation described in #228. Trace how host and socketPath are used for request Host headers, TLS certificate validation, and response hosts. Done means deciding whether to combine them and adding test coverage for these socket scenarios.