Add tests for saved_handler cancellation_slot::emplace exception safety

[ssam18]

Adds a test case to verify that saved_handler::emplace correctly cleans up when cancellation_slot::emplace throws an exception — specifically that the handler has no value after the throw.

This tests the behavior introduced in:

• ad2c9a3 Fix cancellation slot retrieval in saved_handler::emplace
• 0620a68 saved_handler destroys handler if cancellation_slot::emplace throws

[sehe]

The fix (also?) doesn't look accurate to me.

In particular, you applied it to the branch where the documentation claims the immediate executor should be used, however, your bind overrides it with any associated non-immediate executor.

Note that this->get_immediate_executor() correctly invokes boost::asio::get_associated_immediate_executor on the underlying handler h_.

Assuming that you ran into this as a problem in your code, can you share a minimal example where the wrong executor is used? Then we can understand what actually needs to be fixed. I can see two potential causes here:

• the doxygen comment is wrong regarding the use of immediate executor
• the fallback used in https://github.com/boostorg/beast/pull/3075/files#diff-83960c537c353ffc6a1431f079ce863a30ef12d2943b43437aecddcb3c8b7e80R336 is inaccurate? (Might need to be this->get_executor() over wg1_.get_executor()?)

That is, assuming you have demonstrated a case where the wrong executor is effectively used.

[ashtum]

I believe this is related to the issue briefly described in #3047.

Asio recommends using async_immediate inside composed operations to ensure the correct semantics for immediate completion. For example:

asio::async_immediate(self.get_io_executor(), std::move(self));

Internally, this leads to a call to dispatch that looks like:

template <typename CompletionHandler>
void operator()(CompletionHandler&& handler) const
{
  typename associated_immediate_executor<
    CompletionHandler, executor_type>::type ex =
      (get_associated_immediate_executor)(handler, ex_);
  (dispatch)(ex, static_cast<CompletionHandler&&>(handler));
}

If the handler has an associated executor, dispatch wraps it in asio::detail::work_dispatcher, which then dispatches the handler on that associated executor.

In this context, the handler is the composed operation object (self). When the supplied completion_token does not have an associated executor, self falls back to using the stream’s executor. As a result, asio::detail::work_dispatcher is always involved, and the completion handler is guaranteed to run either on its associated executor or on the stream’s executor.

Our current implementation behaves slightly differently. Instead of passing the composed operation object to dispatch, we pass the final handler (h_) directly:

auto const ex = this->get_immediate_executor();
net::dispatch(
    ex,
    net::append(std::move(h_), std::forward<Args>(args)...));

Because of this, dispatch does not attempt to use asio::detail::work_dispatcher with the stream’s executor when the handler lacks an associated executor. Consequently, the earlier guarantee no longer holds:

and the completion handler is guaranteed to run either on its associated executor or on the stream’s executor.