The exit handler should not do reactivation if the status is 'Starting' (or any other operation is currently running)

[KillingSpark]

The exit handler should not do reactivation if the status is 'Starting'. This should be handled by the thread that is currently trying to start the service. The exit event should be communicated via the PidTable in the RuntimeInfo.

This leads to misleading timeout logs for services of type notify (and dbus) if the executable immediately exits.

When fixing this, special care should be taken that socket-activation still works properly, as this resets the status from Started(WaitingOnSocket) to Starting. But the exit handler should in this case apply the correct restarting policy.

So the best plan is probably:

1. Split Status into two fields: current_status, Option
2. Let the exit handler only apply reactivation on Units with an Status that is Started (either waiting on a socket or running properly).
   • If the service was previously stopped or never ran, that starting was a one-time event and should not cause any restarts but just report the appropriate error.
   • It should only mark the entry in the PidTable as Exited and return.
3. The service start routine that waits for notifications/dbus name-grabs needs to regularly check whether the Pid they started is marked as exited in the PidTable and fail with an appropriate error if so.

[KillingSpark]

So this turned out a bit differently. It is fine that the exit handler queues a reactivation for each failed starting try, as long as it marks the service as exited in the pid table. Should be fixed with 5ffd0ff5b06263f4cd3d7fcb2076222ae7562d36