Don't use thread-local var in coroutine & drop superfluous `CpuBoundWork` usage

[yhabteab]

• c915949 - Acquiring a CPU slot just for traversing API user permissions without having to evaluate them is likewise just a wasted semaphore, thus this commit drops its usage.
• 74009f0 - It appears that the Checkable::ExecuteCommandProcessFinishedHandler has been utilised in an erroneous manner. Specifically, the variable is defined as thread_local, yet the callback is executed by a different thread than the one that sets the actual callback, consequently resulting in the actual execute command handler being never called. To address this issue https://github.com/Icinga/icinga2/issues/10144, several functions have been altered to ensure thread safety, and the check results handlers are now executed correctly even from within a coroutine. Apart from that, in all instances where the CpuBoundWork class was utilised, they just wasted costly semaphores, as they were either used to decode JSON responses or process check results, thereby impacting the functionality of the primary components, such as RPC and HTTP connections, that are more crucial than generating a dumb windows check result and processing countless, seemingly inconsequential boost signals. Consequently, this commit eliminates also all instances of CpuBoundWork class within IfwApiCheckTask, and delegates the process check result handling (as suggested in https://github.com/Icinga/icinga2/pull/10140#issuecomment-2321341579) to the global non-I/O thread pool instead.

fixes #10144

[julianbrost]

I'm not really sure about completely dropping the use of CpuBoundWork in IfwApiCheckTask without any replacement, in particular for calling Checkable::ProcessCheckResult(). After all, that function does quite a lot, may lock different objects and so on.

An alternative could be moving this to the other thread pool, i.e. do it the same way how it's done to process regular check results. It uses the following callback where ProcessFinishedHandler() calls ProcessCheckResult() internally: https://github.com/Icinga/icinga2/blob/4c6b93d61775ff98fc671b05ad4de2b62945ba6a/lib/methods/pluginchecktask.cpp#L51-L53 At the end, this callback will end up here: https://github.com/Icinga/icinga2/blob/4c6b93d61775ff98fc671b05ad4de2b62945ba6a/lib/base/process.cpp#L1189-L1196

[julianbrost]

Regarding the individual commits and their messages:

• e24511d5d519dab0f77c58cd9252b9497cbf0c65: Maybe something went wrong here during a rebase, but I don't really see how those two individual changes belong together
• 4f5a9154072a9ec4d136819e1b159927bc09bee7: The message doesn't really describe the changes. I think the message is supposed to say that if fixes #10144, but it does more than that and also, I'd say "thread-safe" isn't really the right word here, that's typically used when referring multiple threads accessing something in parallel (here it's just a logic error that if a job is moved to a different thread, it probably shouldn't rely on a thread-local variable).