fix: prevent EDEADLK self-join in ~CurlHttpOperation on async-thread destruction

[bmehta001]

Problem

modules-repo (cpp_client_telemetry_modules) CI on Linux + macOS crashes during the first ECSClientFuncTests test with:

terminate called after throwing an instance of 'std::system_error'
  what():  Resource deadlock avoided
Aborted (core dumped)

Affects every PR that gets past compile (e.g. modules #277).

Root cause

std::future<long> & SendAsync(std::function<void(CurlHttpOperation &)> callback = nullptr) {
    result = std::async(std::launch::async, [this, callback] {
        long result = Send();
        if (callback) callback(*this);   // <-- callback often holds a strong ref to *this
        return result;
    });
    return result;
}

The callback fired from the async thread is the last owner of the CurlHttpOperation. When it releases its shared_ptr, ~CurlHttpOperation runs on that same async thread.

~CurlHttpOperation then destroys its std::future<long> result member. libstdc++'s ~future -> ~_Async_state_impl calls _M_complete_async -> _M_join via std::call_once. Joining the async thread from the async thread is a self-join — call_once throws std::system_error("Resource deadlock avoided"). Because the throw escapes a noexcept destructor, terminate() aborts the process.

A try/catch around the future or even around an explicit result.wait() cannot rescue this: std::future's destructor itself is noexcept, so the throw lands at the noexcept boundary before any user catch can engage.

GDB confirms (modules CI reproduction, Ubuntu 24.04, libstdc++ 13):

#11 ... __cxa_throw ()                                                                                                     
#12 ... std::__throw_system_error(int) ()
#14 std::__future_base::_Async_state_impl<...CurlHttpOperation::SendAsync...>::~_Async_state_impl() at /usr/include/c++/13/future:1765
#15 ... std::_Destroy<...> ...                                                                                             
#17 ... std::_Sp_counted_ptr_inplace<_Async_state_impl<...>>::_M_dispose()
#22 std::__basic_future<long>::~__basic_future ()
#23 std::future<long>::~future ()
#24 Microsoft::Applications::Events::CurlHttpOperation::~CurlHttpOperation () at HttpClient_Curl.hpp

Fix

Move the future onto a detached helper thread before it can destruct on the async thread. The helper is by definition not the async thread (we'd only be on the async thread if its work has already completed, which is the only way ~CurlHttpOperation could run there), so the implicit join completes in microseconds.

On the common path — destruction from the caller thread — the helper thread spawn is also nearly free: the implicit join sees the work is done and returns immediately.

if (result.valid()) {
    std::thread([f = std::move(result)]() mutable {
        // f goes out of scope here on a fresh thread (!= the async thread),
        // so the implicit ~future join cannot self-deadlock.
    }).detach();
}

Verification

Verified on Linux GCC 13 with sister-main + modules-#277 linked (the exact configuration that crashed):

• Before: ECSClientFuncTests.GetConfigs aborts at first test in suite.
• After: All 25 ECSClientFuncTests pass; all 113 FuncTests pass ([ PASSED ] 113 tests).

Why this hasn't been seen on sister CI

The crashing path is ECSClientFuncTests, which is in the modules repo (lib/modules/exp/tests/functests/). Sister CI doesn't build lib/modules, so the crash is invisible there. It's only exposed when sister is linked with modules (i.e. the modules-repo CI configuration). That's why master modules CI has been red on Linux/macOS for ~50 consecutive runs — the redefine bug (#1473, merged) was masking this one. Once #1473 cleared, this surfaced as the next gate.

Risk: low. One short-lived thread per ~CurlHttpOperation invocation when result is still valid. Pure additive — no API change, no behavior change for already-joined futures.