Extended functionality for `async_rw_mutex`

[msimberg]

While using async_rw_mutex a few additional use cases for async_rw_mutex have popped up. Implementing them in pika would simplify implementations in DLA-Future and/or allow certain functionality that would otherwise not be possible.

Obtaining a nested async_rw_mutex from an existing one

This is useful for the "sub pipeline" use cases in DLA-Future. This comes in two flavours:

async_rw_mutex<T> async_rw_mutex<T>::nest;

i.e. returning a new async_rw_mutex which provides sender access that is strictly in between all previous and later accesses of the original async_rw_mutex, even if accessed out of order.

The other flavour is:

sender_of<async_rw_mutex<T>> async_rw_mutex<T>::nest;

This is otherwise the same but the nested async_rw_mutex comes through a sender. It's possible that this could be implemented more efficiently than the former. However, the former can be used to obtain the latter, so the former is at least as useful as the latter. The latter requires a sync_wait to recover the former which we want to avoid.

Initializing the protected value in async_rw_mutex with a sender

We currently have some use cases where we initialize the value contained in the async_rw_mutex with a default constructed value or similar, only to overwrite it afterwards with a value obtained from a sender. Allowing construction of async_rw_mutex through a sender of the contained type would avoid requiring default constructibility of the contained type. It would likely also be slightly simpler and possibly avoid a few allocations.

Optimizing nested read-after-read access

A read in a nested async_rw_mutex after a read in a parent async_rw_mutex can be merged into one concurrent read. This is currently not implemented and awkward/impossible(?) to implement in DLA-Future on top of async_rw_mutex. Implementing this within async_rw_mutex would likely result again in fewer allocations and hopefully fewer unnecessary accesses to async_rw_mutex.