Always call HttpUtility::SendJsonBody() with a boost::asio::yield_context

[Al2Klimov]

to respect l_FlushThreshold in all messages.

Especially l_FlushThreshold may now be lowered in the future without re-evaluating all possible responses.

Side effect: all HTTP responses use chunked encoding now.

By the way...

• CpuBoundWork#CpuBoundWork(): don't spin on atomic int to acquire slot #9990 (comment) requested this being a separate PR to not further slow down CpuBoundWork#CpuBoundWork(): don't spin on atomic int to acquire slot #9990
• Most of this PR is passing boost::asio::yield_context deeper through the code, but you may want to look at the adjusted unit tests and on my second commit

[julianbrost]

As you seem to be putting more effort into this one recently:

to respect l_FlushThreshold in all messages.

Especially l_FlushThreshold may now be lowered in the future without re-evaluating all possible responses.

I'm not immediately convinced if this is a good idea. In particular, all the handlers that make use of chunked encoding so far where checked for patterns that would cause problems with yielding coroutines. In particular:

// This is safe.
ObjectLock olock(something);
HttpUtility::SendJsonBody(response, params, result);

// Now it becomes unsafe as `yc` may yield and resume on a different thread,
// but C++ std mutexes must be released on the same thread.
ObjectLock olock(something);
HttpUtility::SendJsonBody(response, params, result, yc);

So this change means the same burden for every single handler.

Also, chunked encoding also isn't something that we must use just for the sake of it, it's sufficient if handlers that are expected to generate large responses use it.

[Al2Klimov]

Damn.