Make PARSEC a daemon about parsec

[hug-dev]

Agree to both points.
I have written some research I made about the subject and what I think we should be doing:

There seems to be two kinds of daemons:

• "traditional" SysV daemons which contain a double-forking mechanism to separate themselves from their parent process and the TTY they are linked to. They redirect themselves their standard file descriptors to a file or system wide logging. The crate daemonize works like that.
• "modern" systemd daemons where systemd itself manages the daemons which do not have to do anything special apart from having a graceful shutdown mechanism. This can be done by implementing a SIGTERM signal handler (signal that is sent to the daemon when systemd wants to close it.) systemd needs a service file that describe the service type and its logging mechanism. Logs can be redirected easily so that they can be viewed with the journalctl, something like journalctl -u parsecd.service. There are also advanced features of systemd to automatically start-up the daemon whenever a connection is received on the socket, and not have it running all the time.

I am mostly inclined to follow the modern, systemd, process of daemonization and I see for that the following tasks:

1. Create a .service file and put it at the root of this repo (same way as containerd does)
2. Implement a handler of the SIGTERM signal to cleanly shutdown PARSEC (send to all thread a message through a channel for them to return and join them)
3. Adds CI tests where PARSEC is run as a daemon, with systemctl commands.

Separate but linked tasks:

• With #36, replace all println calls with a real logging system (log + env_logger for example). (Possibly add log tests?)
• Investigate socket activation of PARSEC

Note: systemd is a Linux only daemon manager, which is not on MacOS. The service will need to have OS dependant (#[cfg]?) code and still work by just running cargo run on other OSes. We will need to investigate daemon manager on the other OSes we want PARSEC to run on.

Ressources: simple description, daemon man page, types of services, Go example

[justincormack]

logging to stdout is the normal way for daemons to run now; systemd or whatever will handle redirecting logs to wherever, so it is not necessary to change that. We should have a clean shutdown.

[ionut-arm]

The points above seem good, but I have a few questions/points:

• Log tests are probably overkill. Manual checking should suffice
• Given the architecture of PARSEC, how will the socket activation fit into it? I agree that it's a nifty tool, but only as long as it doesn't open us up to someone tricking the system
• We should future-proof at least a tiny bit, in case we need to make PARSEC a Windows service too :)

[hug-dev]

Agree to all points.
I think socket activation is an advanced topic that will need more look into once a basic service is working. Will look into simple and notify services at first, with no socket activation (the service will initialise its own socket). Socket activation will also be socket dependant and I don't know how it would interact if we have other kinds of listeners.
I will make sure that the normal behaviour cargo run, still works on other OS.

[hug-dev]

CC @paulhowardarm for your information