mount_service: possible implementation changes

Right now the new mount_service protocol works by first gaining root capabilities via fuservicemount being setuid, then communicating with a socket-activated systemd service to run the actual filesystem implementation in a sandboxed systemd unit.

I think there could be an improvement to the design by instead moving the privileged parts into a systemd socket activation unit, and having that privileged service spawn the containerized systemd unit as a child transient unit, or via socket activation with a root-only socket file.

Ie. The fuservicemount binary would be a non-setuid binary, and simply communicate with a socket in /run that is backed by a privileged socket-activated service. Upon activation, the service would use the peer credentials to enforce limits such as `mount_max`, and configure `/dev/fuse`. Finally, it would spawn the sandboxed systemd unit to run the filesystem, using `--scope` to transfer the file descriptors to the new process, or using socket activation with a socket file that only root can read and write to.

The advantage of this approach over the current design is compatibility with containers with the no_new_privileges security feature enabled. That disables privilege-elevation through execve (ie. setuid and setcaps binaries), but the use of systemd socket activation would still work.

The other advantage is limiting the access of the filesystem sandbox startup to the privileged service, which can prevent issues arising from parsing bugs (not privilege escalation, but potentially DOS issues by escaping the systemd resource-control group).