task<> scheduler affinity (#290)

[janondrusek]

This commit implements scheduler affinity -- aka "sticky" scheduling -- in unifex::task<>. The idea is that it is impossible for a child operation to cause the current coroutine to resume on the wrong execution context.

• task<>-based coroutines track and propagate the current scheduler
• at_coroutine_exit remembers current scheduler from when the cleanup action is scheduled
• schedule always returns an instance of sender_for<schedule, the_sender>, which is also a scheduler_provider
• scheduler affinity when co_await-ing senders in a task<>-returning coroutine
• scheduler affinity when co_await-ing awaitables in a task<>-returning coroutine
• awaitables and senders that are blocking_kind::always_inline don't get a thunk
• More senders and awaitables support compile-time blocking queries
• co_await schedule(sched) is magic in a task<>-returning coroutine: it changes execution context and schedules a cleanup action to transition back to the original scheduler

Move implementation of special co_await behavior of scheduler senders out of task.hpp

Hoist untyped RAII containers for coroutine_handle<> out of task<> and its awaiter (#329)

While looking at the binary size impact of adopting coroutines with unifex::task<>, I noticed that a number of operations on coroutine_handle<T> are expressed in unifex::task<> as if they depend on T when they don't. The consequence is extra code.

This diff creates a coro_holder class that uniquely owns a coroutine_handle<> and makes unifex::task<> inherit from it. We technically lose some type safety, but it's still correct by construction. This change saves about 1.5 kilobytes in one of our apps.

Similar to the above, I noticed binary duplication due to false template parameter dependencies in unifex::task<>'s awaiter type.

This diff hoists a non-type-specific RAII container for a coroutine_handle<> that stores the handle as a std::uintptr_t so that task's awaiter can use the low bit as a dirty flag. This change saves another ~1.5 kilobytes in one of our apps.

Fix scheduler affinity (#405)

• Fix scheduler affinity

We have been storing a task<>'s scheduler as an any_scheduler_ref, which has proven to be a source of use-after-free bugs. This change switches all the any_scheduler_refs to any_schedulers, fixing the lifetime issues.

Make task<>'s thunk-on-resume unstoppable (#495)

• Make task<>'s thunk-on-resume unstoppable

When awaiting an async Sender that swallows done signals (such as let_done(never_sender{}, just)), the user-level code looks like it swallows done signals:

// never cancels
co_await let_done(never_sender{}, just);

However, task<>'s Scheduler affinity implementation transforms the above code into this:

co_await typed_via(let_done(never_sender{}, just), <current scheduler>);

The schedule() operation inside the injected typed_via can emit done if the current stop token has had stop requested, leading to very non-obvious cancellation behaviour that can't be worked around.

This diff introduces a pair of regression tests that capture the above scenario, and the analogous scenario of awaiting an async Awaitable that completes with done. The next diff will fix these failing tests.

• Change task<>'s thunk-on-resume to be unstoppable

This diff fixes the broken tests in the previous diff.

Respect blocking_kind in let_value() (#381)

• let_value() would always assume blocking_kind::maybe, which results in potentially unnecessary reschedule on resumption
• replicate blocking_kind customization from finally()

fix variant_sender blocking kind (#474)

add unifex::v2::async_scope (#463)

• simpler than unifex::v1::async_scope (nest() and join())
• does not support cancellation

fixing linter error (#414)

move deduction guide to namespace scope for gcc-10

in scheduler concept, check copy_constructability after requiring call to schedule()

work around gcc-10 bugs

avoid warning about missing braces in initializer

[ericniebler]

Hooray! 🙌

[ispeters]

Two small comments; otherwise, LGTM.