Bug 41615

Probably not very big of a problem, which is why we're merging STS although it has this limitation. The API has sufficient flexibility, though, to allow adding Unix socket support later.

Reasons it was left out originally:
 - TCP sockets allow us to more conveniently associate ongoing connections with the remote contacts they're from as long as the CM supports Socket_Access_Control_Port (gabble does), as there are only so many (256) different 8-bit credential byte values for Unix, and credential bytes can't be even used with all protocols as they are in-line with the protocol bytestream
 - I don't know of any services which couldn't be configured to also listen on TCP. X11 and cups can be, for example - so they're likely to be exported as TCP services due to the above limitation with connection monitoring
 - The spec only requires CMs to support TCPv4 sockets too. Gabble supports all the address types anyway though.

Reasons why it would still be nice to have one day:
 - Maybe better performance than TCP sockets for the same service? Dunno how much better, or if at all on practical systems.
 - Credentials AC allows restricting the processes allowed to connect to those from the same UID (like our protocol backend), without explicitly authenticating using the tube payload protocol
 - After all, some services might be really Unix only. At least X11 is in its usual distro configs (-nolisten tcp) and it's a bit crappy to have to change that.