Extend NUT server-client communications to optionally use a Unix socket (or WIN32 named pipe)

[jimklimov]

An idea I did not find in the issue tracker but I think saw floating around some documentation during recent reformatting effort: for security and certain simplification, it may make sense for upsd data server and clients (upsmon, upsc etc.) both running on a local system to not require a functional IP stack and support communications with a Unix socket file as well.

This could be useful for containers without networking (or networked into different LAN segments), embedded systems (especially if they only need the IP stack for NUT programs to chatter), generally for NUT programs to be able to start before networking appears in kernel or is brought online with at least localhost (IPv4/6) addresses bound, and any number of other conjured-up reasons.

There is quite a bit of industry-wide precedent, e.g. with popular databases. After all, decades of sockets over FS/IP/... abstractions are there for a reason.

Initial-access security (similar to IP firewall) would be managed by POSIX permission (or ACL) for the file system based sockets, or eventually SELinux or equivalent constraints on newer OSes. Not sure about Windows named pipes.

Syntax-wise, we could support it as a re-use of the host specification starting with a slash or backslash depending on platform, and probably ignoring any :port part:

# POSIX
:; upsc myups@/run/nut/upsd.sock

# WIN32 (pedantic)
:; upsc -l \\.\pipe\upsd.sock

# WIN32 (maybe some shortcut would be nice?)
:; upsc -l /upsd.sock

Implementation seems like a low-hanging fruit, building upon all we've done before...

CC @arnaudquette-eaton @clepple : WDYT ?