WIP: multiprocessing

[cgwalters]

I've been wanting to do this for a long time, but was too intimidated
at the thought of doing it in C.

One big thing to do here is to move the transaction heavy lifting
into a subprocess. That would be a lot of work; just forking
off the dnf fetching would help solve
#897

Another case where I want do to this is to drop privileges for
the curl bits we do now for rpm-ostree install http://.

There's not a lot here yet, just me experimenting with Servo's
"ipc-channel".

[cgwalters]

Some thoughts:

Sandboxing

I think we should use bwrap instead of https://github.com/servo/gaol except...it'd be nice to share seccomp filter generation when we get to that point. But simply using dynamically allocated uids would be a big win.

I wonder though how much we should try to do sandboxing in the compose case which nowadays we expect to always be inside a container itself. Maybe we just end up using multiple processes but don't sandbox much.

If we go that route then it may argue to use systemd's support for e.g. seccomp. Only wrinkle there is then we end up with multiple units (I don't know of a way to basically make systemd-run a "child" of our existing unit).

And abstracting over "use systemd versus not" would get ugly. Forcing on systemd in the compose case would get ugly.

ipc-channel

The "send channels over a oneshot server which uses a socket in /tmp" pattern is weird; we should be able to change ipc-channel to support us passing the socketpair() over a fork, no tempdir involved

I wonder whether we really want a higher level abstraction, a bit more like what https://github.com/varlink is doing (e.g. having an interface definition schema is really nice).

[cgwalters]

I still think this is a good idea - basically what we should do is fork off everything we're doing in a transaction as a subprocess. But what's here isn't very helpful for that right now.