Add Unix domain socket support

[rschmitt]

This change adds Unix domain socket support. The sync client uses JUnixSocket, which provides synchronous UDS support through the legacy java.net.Socket API; the async client uses the JEP 380 implementation of UDS through the java.nio.channels.SocketChannel API (requires JDK16 or later).

Since the synchronous client is tightly coupled to the Socket API, we can't trivially use JEP 380 UDS support. We would first have to write an adapter to implement the Socket API, backed by a JEP 380 UDS SocketChannel. This would require us to implement features like socket option configuration, connection timeouts, and socket timeouts; we would also have to implement APIs like getInetAddress() which don't actually make sense in a UDS context. This is probably doable (JUnixSocket does it, albeit with a different implementation strategy based on native code), but it's not trivial.

The asynchronous client is the other way around: it supports JEP 380, but not JUnixSocket. The issue here is more subtle: JDK and JUnixDomain channels cannot be mixed in the same selector, and since JUnixDomain does not provide an implementation of TCP/IP channels, supporting JUnixSocket in the async client would require substantial rework in the IO reactor. Since JDK8 is end-of-life next year, I doubt this is worth doing unless we can find some clever way of integrating the new channel type with minimal churn.

Unix domain socket support is exposed through the RequestConfig API. A path to a Unix domain socket can be provided as a client-wide default through setDefaultRequestConfig, or on a per-request basis through setConfig. Currently, proxies and TLS are not supported through UDS. The former feature seems unnecessary, but the latter is likely worth adding at some point, since contacting an HTTPS endpoint over UDS (sometimes denoted by the URI scheme https+unix) is not unheard of.

[ok2c]

@rschmitt It is a big one. Please allow me a few days to get around to it.

[rschmitt]

I suggest reading the diff from the bottom up. It just flows more logically that way: example code, connection changes, routing changes, integration test changes.

[michael-o]

Final word has @ok2c

[ok2c]

@rschmitt Looks good to me