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 IfwApiCheckTask uses thread-local variable in coroutine #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 Don't use thread-local var in coroutine & drop superfluous CpuBoundWork usage #10140 (comment)) 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:

icinga2/lib/methods/pluginchecktask.cpp

Lines 51 to 53 in 4c6b93d

	callback = [checkable, cr](const Value& commandLine, const ProcessResult& pr) {
	ProcessFinishedHandler(checkable, cr, commandLine, pr);
	};

At the end, this callback will end up here:

icinga2/lib/base/process.cpp

Lines 1189 to 1196 in 4c6b93d

	if (m_Callback) {
	/*
	* Explicitly use Process::Ptr to keep the reference counted while the
	* callback is active and making it crash safe
	*/
	Process::Ptr process(this);
	Utility::QueueAsyncCallback([this, process]() { m_Callback(m_Result); });
	}

[julianbrost]

Regarding the individual commits and their messages:

• e24511d: Maybe something went wrong here during a rebase, but I don't really see how those two individual changes belong together
• 4f5a915: The message doesn't really describe the changes. I think the message is supposed to say that if fixes IfwApiCheckTask uses thread-local variable in coroutine #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).