* Use systemd socket activation
* Pass a new command line argument --systemd-socket-activation to the daemons if running on Linux
* Install .socket files
* Systemd services depend on their sockets
* Implement sd_listen_fds in OCaml
* Set FD_CLOEXEC in sd_listen_fds
* README: add comment about socket paths
* Linux systemd scripts: Rename albatross_stat -> albatross_stats
this makes it much easier to reason about the initialization.
for production, init scripts should enforce the dependency order
for testing, provide your own if desired
//cc MagnusS
also move enable_stats and retry_connections up (before exit codes)
* Make albatrossd wait for other sockets to appear if --retry-connections is specified
* Connect to log/console before creating main socket
* Disable stats by default unless --enable stats is specified
it used to only contain service, and used the same string for the bridge. This
is not flexible enough to run off-the-shelf unikernels (configured for bridge
"service" and "management" on multi-homed servers). The old behaviour is the
new default (i.e. "--net=service" creates and attaches a tap device to bridge
"service", and passes "--net:service=tapYY" to the solo5 tender). But it is more
flexible now: "--net=service:other-bridge" will create a tap device attached to
"other-bridge" and pass "--net:service=tapYY" to the tender. This way, there's
no need to match bridge names on the actual server with network device names of
the unikernels.
NB: this is (mostly) backwards-compatible: the on-disk data structures are
versioned (and the version is bumped with this PR), an old albatross client can
send "create" commands to a new server. But a new client will get a parse error
from an old server - which is fine taking into consideration the deployment
base.