Reportedly `systemd-run --scope` still got killed by the service
manager; see #4615. The suspected cause is that `scope` units are run by
the `systemd-run` process itself and inherit the caller's execution
environment (see systemd-run(1)). To fix this, we use a systemd
`service` unit instead, which is run and managed by PID 1 - hopefully
this will isolate us sufficiently so that we don't get terminated along
with `jellyfin.service`.
systemd-run(1) runs `systemctl restart` in an isolated systemd unit
that is not subject to process termination as jellyfin.service is shut
down. We adjust the sudoers configuration for this new usage, removing
the old config, since restart.sh is the only user of the sudoers
policy.
Additionally we change `systemctl start` to `systemctl restart` since
there was a race condition where jellyfin.service was not fully
stopped by the time this ran, so `systemctl start` became a noop.
`systemctl restart` on the other hand works whether jellyfin.service is
stopped or not.
The at(1) hack (and the usage of `start` instead of `restart`) is left
in for other init systems since I cannot test on those systems, and
because I don't know of any systemd-run(1) equivalent (although it may
be a non-issue since alternate init systems do not keep track of daemon
children nearly as aggressively as systemd does).
