Review client support for Unix sockets

[sbordet]

The HttpClient support for Unix socket needs to be reviewed.

Currently, it is implemented as a transport for HttpClient, but Unix sockets are really a replacement for network sockets, rather than a new way to encode HTTP requests and responses over the "wire", as Unix sockets support TCP (among other protocols, included UDP).

The current implementation also only opens just one socket for the whole transport, and inherits from the HTTP/1.1 transport.
I don't think this is correct, as it won't be possible to send concurrent requests over a single Unix socket, as much as it's not possible with a single network socket.
And there is nothing that forbids a Unix socket to transport HTTP/2 or FastCGI, rather than only HTTP/1.1, while now HTTP/1.1 is hardcoded.

Class UnixEndPoint seems unnecessary, as JNR returns a SocketChannel so the current SocketChannelEndPoint is enough.

The only difference for Unix sockets is really how the java.nio.Selector is created, as it needs to plug in the JNR implementation.

In light of #132 and #1350 - i.e. having a single HttpClient be able to speak multiple protocols dynamically, we need one more degree of freedom: whether to open a network socket or a Unix socket for a given destination.
But perhaps this degree of freedom is another issue.

[sbordet]

See also #1881, #2014, #2634, #3136.

[joakime]

Class UnixEndPoint seems unnecessary

There are SocketAddress differences that need to be handled correctly.
JNR implements SocketAddress (via UnixSocketAddress implementation), not InetSocketAddress like all of our other EndPoint implementations.

[sbordet]

@joakime perhaps, but I think it's enough a ternary expression in SocketChannelEndPoint when retrieving the addresses.

[sbordet]

Addressed in #3474.