Server: add setuid/setgid capabilities

[picnoir]

We add tree new CLI flags to cty serve:

• --unix-socket-path: path pointing to the unix socket. Defaults to
  ./curiosity.sock
• --user-name: name of the user we want to run curiosity for.
• --group-name: name of the user we want to run curiosity for.

On a production setting, we often like to bind the unix sockets to
/run. You need to be root to do that. The idea is to start the
software as root, let it bind its socket in /run, then setuid/setgid
the process to its definitive user/group.

We decided not to change the state.json uid/gid. It means that we'll
have to "manually" set the appropriate permission. Likely via the
service pre-start procedure. It might be a bad idea we want to
revisit, it might be the right way to do it, only experience will
tell on that one.

We also update the curiosity systemd service to reflect this change.

[noteed]

Aren't some end-of-line backslashes necessary for continuation lines ?

[noteed]

So, let me try to rephrase what it's doing: the process, typically cty serve, starts as root, so that it can create a UNIX-domain socket in /run. It does create the socket, changes itself its ownership to curiosity:curiosity, then sets its own uid/guid to the same thing.

So far so good.

I was thinking initially to let dynamically users of the web application start and stop the UNIX-domain socket serving thread. This is what I did for the email processing thread (it's nice to kill that thread and see that outgoing emails remain in the TODO state when the thread is not running; and in cty run, that thread is not running, so that actually processing emails can be an explicit command in the cty run script).

For the UNIX-domain thread, that's not really necessary (to kill/spawn it while the HTTP server is running). But what if I wanted that to be possible ? Once the server has change its own uid/gui, could that thread be started again and create the socket in /run ?

So as I've said, that's not really a problem.

Do you think it's elegant to change the uid/gui in a forkIO thread though ? Here too it's not a big deal if we let it that way for now.