infra: encapsulate usage of asio co_spawn

[canepat]

This PR rationalises and encapsulates the usage of boost::asio::co_spawn in our codebase with the following objectives:

• define in one place which flavours of completion tokens for co_spawn we use (e.g. we should not use detached anywhere)
• make the code at call site more readable and less verbose

The result is three different spawn functions:

1. spawn: it's co_spawn called with use_future returning the future result to the caller (who decides at the call site if waiting or not)
2. spawn_and_wait: same as above but returning the result after waiting for the future
3. spawn_and_async_wait: it's co_spawn called with use_awaitable

The only exception to the above rules is in our custom versions of awaitable_wait_for_all and awaitable_wait_for_one, where I've deliberately decided to leave the code as similar as possible to Asio for ease of comparison, without introducing a custom spawn_deferred. I would like to hear what @battlmonstr thinks about this, though.

Extras

• Fixes infra: remove preprocessor define for co_spawn_sw #2237
• customise name of gRPC context threads in log

[bzawisto]

Small nitpick, but perhaps this and all typenames below could be replaced by c++20 concept, i.e.:
requires boost::asio::is_executor<Executor>::value || boost::asio::execution::is_executor<Executor>::value ?

[canepat]

Sure, I just copy-pasted from Asio to make it work in the first place, then I forgot to refactor. Thanks!

[battlmonstr]

I'd like that co_spawn + use_awaitable be our default. Ideally it should have the shortest name. Spawn with future should only be used in async-sync adapters or tests, so a longer name should be fine.

I suggest names like:

1. spawn_future
2. spawn_future_and_wait or spawn_future_and_get (do we really need those std::future wrappers?)
3. spawn or spawn_task (spawn_task is friendlier for "find-and-replace" later)

If you prefer to keep the refactoring as is, and not rename, at minimum consider that spawn_and_wait and spawn_and_async_wait names are a bit inconsistent/misleading, because they don't wait in the same sense.

Nevertheless, overall this is a good idea to cut the useless 3rd parameter and simplify.

[canepat]

I'd like that co_spawn + use_awaitable be our default. Ideally it should have the shortest name. Spawn with future should only be used in async-sync adapters or tests, so a longer name should be fine.

Sure, I think you have a good point here.

I suggest names like:

1. spawn_future

I had this name in my first iteration locally, so it seems to be a good candidate!

2. spawn_future_and_wait or spawn_future_and_get (do we really need those std::future wrappers?)

I'll check if this is used in many places or maybe only as test facility in test_util::ContextTestBase.

Recap:

1. spawn_future
2. spawn_future_and_wait (if needed)
3. spawn_task

@battlmonstr do you prefer leaving awaitable_wait_for_all and awaitable_wait_for_one as they are to keep them closer to the original Asio code or introducing spawn_deferred? We use asio::deferred completion token only there.

[battlmonstr]

@canepat yes, I'd leave it inside infra as is. It feels fine to use co_spawn directly inside the infra lib.