Fix WinHttpRequest destructor hang when the request context is never bound

[Dan Cristoloveanu (dcristoloveanu)]

Fixes #7352

Problem

WinHttpRequest::~WinHttpRequest() closes the request handle and then waits for
WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING before returning. That barrier is deliberate and
necessary: WinHTTP is used in async mode (WINHTTP_FLAG_ASYNC), the callback context is a raw
pointer to the WinHttpAction owned by the request, and the callback also dereferences
m_httpRequest. Returning before HANDLE_CLOSING would let a WinHTTP worker thread touch freed
memory.

However, WinHttpAction::StatusCallback() discards every notification that arrives with
dwContext == 0, and the context is bound to the handle only by WinHttpSendRequest() — while
the status callback is registered much earlier, at the end of the constructor. Any request
destroyed in between (for example when an exception is thrown while preparing headers or querying
the body stream length) therefore closes its handle, receives HANDLE_CLOSING with no context, has
it dropped, and blocks in WaitForAction forever. The wait uses a default-constructed
Azure::Core::Context, so ThrowIfCancelled() never fires and the poll loop spins indefinitely —
the thread is lost for the lifetime of the process.

CompleteActionWithError() intentionally does not signal while waiting for HANDLE_CLOSING, so
the REQUEST_ERROR / ERROR_WINHTTP_OPERATION_CANCELLED notification that WinHTTP raises when
closing a handle with a pending operation does not release the waiter either.

This is the hang that remains in the window #6637 addressed for the FailFast case; that PR's own
comment already observes that "the initiateAction call is a call to WinHttpSendRequest which
establishes the SendContext".

Fix

Bind the context to the request handle in the constructor with
WinHttpSetOption(WINHTTP_OPTION_CONTEXT_VALUE, ...), immediately before registering the status
callback. HANDLE_CLOSING is then always delivered with a valid context, so the destructor's
barrier always completes. WinHttpSendRequest() continues to pass the same value, which is
idempotent.

The barrier itself is unchanged — the fix makes it satisfiable rather than removing it.

Alternatives considered

• Track whether the context was bound and skip the wait when it was not. Safe for the same
  reason the bug exists (with no context every callback is already dropped, so there is nothing to
  synchronize against), but smaller in scope and leaves HANDLE_CLOSING unobservable.
• Give the destructor's wait a deadline. Rejected: abandoning the wait permits a WinHTTP worker
  thread to invoke the callback after WinHttpAction/WinHttpRequest are destroyed, converting a
  hang into a use-after-free.
• Signal the event from CompleteActionWithError() during close. Rejected for the same reason:
  it would release the waiter before HANDLE_CLOSING, which is precisely what the barrier prevents.

Test

sdk/core/azure-core/test/ut/win_http_transport_test.cpp adds
WinHttpTransport.RequestThatFailsDuringSetupDoesNotHang.

SendRequest() calls request.GetBodyStream()->Length() before WinHttpSendRequest(), and
BodyStream::Length() is not noexcept, so a body stream that throws from Length() enters the
window deterministically. The test needs no network: WinHttpOpen(), WinHttpConnect() and
WinHttpOpenRequest() only allocate handles, and the request fails before anything is sent.

The work runs on a detached thread guarded by a 30 s future wait, so a regression fails the test
instead of hanging the CI run (a blocked destructor cannot be joined).

Verified against the vendored 1.16.3 sources in a downstream consumer: an equivalent test hangs
and fails on the 30 s timeout without the product change, and passes in 0.76 s with it. A leak
checker also reported the abandoned WinHttpRequest from
WinHttpTransportImpl::CreateRequestHandle() before the fix, and no leaks after.

Pull Request Checklist

• C++ Guidelines
• Doxygen docs — n/a, no public API change
• Unit tests
• No unwanted commits/changes
• Descriptive title/description
  • PR is single purpose
  • Related issue listed
• Comments in source
• No typos
• Update changelog
• Not work-in-progress — opened as a draft for maintainer feedback on the approach
• External references or docs updated
• Self review of PR done
• Any breaking changes? — none; behavior only changes in the case that previously hung

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
8 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.