Rework locking in config update

[julianbrost]

Pull request #8308 introduced a spin lock to work around the fact that both Boost and STL mutexes require to unlock from the same thread that acquired the lock. There should be a better way to do this. This issue is created to not forget about this and discuss alternative solutions to solve this properly.

[julianbrost]

The current control flow is as follows: a new thread is started which acquires the mutex and spawns a process with a callback to be run when the process terminates. This callback then unlocks the mutex when it's done. To be able to use std::mutex, this unlock operation has to be moved to the thread that acquired the mutex. I see two relatively easy to implement options:

1. Extent icinga::Process with a method ProcessResult& WaitForResult() that blocks until the process exited and then returns the result. Use this method instead of the callback mechanism.
2. If the general idea for icinga::Process should be to provide an asynchronous interface, one could also implement basically the same within the callback, i.e. create a condition variable that is updated in the callback and then wait for it in the process that acquired the mutex.

[icinga-probot]

Closed this issue because #8510 has been merged.