switch to being a systemd service

[cgwalters]

Right now we have a lot of simplicity by not running under systemd. But there are a lot of advantages to doing so; see e.g. https://github.com/coreos/bootupd#questions-and-answers

All of the below applies to us too:

• Why is bootupd a daemon?

It's not, really. The name was intended to be "bootloader-upDater"
not "bootloader-updater-Daemon"; the choice of a "d" suffix is
in retrospect probably too confusing.

At a technical level, yes there is a socket-activated systemd service
which will spawn a bootupd.service. However - the service will
very quickly auto exit. There's nothing long-running, so it's
not really a daemon.

The rationale behind this design is:

• Using a systemd service provides a robust natural "locking"
  mechanism.
• Using a systemd service ensures that critical logging metadata
  always consistently ends up in the systemd journal, not e.g.
  a transient client SSH connection.
• systemd services can easily have sandboxing applied, and
  while bootupd is obviously privileged we can still make use
  of some of this.
• Ultimately, we do probably want a non-CLI API (whether that's
  DBus or Cap'n Proto or varlink or something else). Having
  a socket (without a defined stable API) is preparatory work for that.

[cgwalters]

Was thinking about this more recently, and there's an alternative path where we actually default to running in a container instead (maybe crun executed on the host rootfs) - but the point is that we avoid relying on too many systemd features because we ideally also support being executed from a privileged container for updates.

[cgwalters]

If we ran from a systemd unit by default it'd make it easier to use https://systemd.io/CREDENTIALS/ for container pull secrets; also xref containers/image#1746

[cgwalters]

I think this is mostly a dup of #4 in the sense that for the most part being a service should be transparent and what most people care about is the APIs.