[BUG] Do not queue a curl session closed by the Retry-After cap

[ThomsonTan]

Fixes #4631

Changes

When a retryable response carries a Retry-After beyond max_backoff,
PerformCurlMessage() closes the session with Cleanup(). The IO loop then
asked IsRetryable() again, still got true, and queued the closed session
at the server's retry time. doRetrySessions() stops at the first entry
that is not due, so that entry held back every later retry on the client
and kept the background thread alive. WaitBackgroundThreadExit() and
~HttpClient() could not join until the server's time, and the loop
busy-spun meanwhile.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.64%. Comparing base (4679325) to head (e053836).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4632      +/-   ##
==========================================
+ Coverage   86.53%   86.64%   +0.12%     
==========================================
  Files         525      525              
  Lines       20482    20482              
==========================================
+ Hits        17722    17745      +23     
+ Misses       2760     2737      -23     

Files with missing lines	Coverage Δ
...lemetry/ext/http/client/curl/http_operation_curl.h	90.91% <ø> (ø)
ext/src/http/client/curl/http_client_curl.cc	93.19% <100.00%> (-0.01%)	⬇️
ext/src/http/client/curl/http_operation_curl.cc	63.20% <100.00%> (+1.99%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lalitb]

Non-blocking: could we add a separate case that calls WaitBackgroundThreadExit() immediately after the capped request finishes, without sending the second request?

Here, the original bug spends the 30 seconds waiting for the second request to retry, so the later join can still return promptly. The retry assertion catches the bug, but a separate case would directly cover the shutdown scenario from #4631.

[ThomsonTan]

Added RetryAfterBeyondMaxBackoffDoesNotDelayShutdown which calls WaitBackgroundThreadExit() right after the capped request, fails after about 30 s against the pre-fix IO loop, and passes with this fix.

[lalitb]

LGTM, thanks for the quick fix!