[BUGFIX] Complete an OTLP HTTP request on every state its client can end on

[thc1006]

Fixes #4425.

ResponseHandler::OnEvent decides whether a request is over from a switch that names seven states. The client can end a transfer on three more, and the switch below it recognises all three and logs them:

State	Reported as over	Logged
CreateFailed, ConnectFailed, SendFailed, SSLHandshakeFailed, TimedOut, NetworkError, Cancelled	yes	yes
Destroyed, ReadError, WriteError	no	yes

So a request that ends on one of those three arrives, is described, and is then dropped. It never reaches Unbind, its result callback never runs, and its session is never released. ForceFlush and Shutdown have nothing to wait on but their own deadlines, and the caller is left waiting for a callback that is not coming.

The three states join the same switch. Nothing else changes.

Why the exporter has to answer them

The bundled curl client does not currently produce any of the three, so this is reached through the installed HttpClient interface by a client the user supplies. That interface is a supported extension point, SessionState is part of it, and the header describes these as error reading response, error writing request and a session destroyed. An exporter cannot decide which of them a client is allowed to use.

Ordering does not change. stopping_ is a compare-exchange and the first writer wins, so one of these arriving after a response has already been reported still reports nothing. That is what the last case below holds.

Checks

Two cases, both in otlp_http_exporter_custom_client_test.cc, driven by the existing nosend client. The first walks the three states, delivering each as the only terminal event, and requires the result callback to have run exactly once with kFailure and ForceFlush with a 50 ms deadline to report success rather than wait it out. The second delivers a response first and then each of the three, and requires the callback count to stay at one.

Removing the three lines from the switch does not turn those cases red. It hangs the whole binary: without them the request never settles, so the OtlpHttpClient destructor waits for a session that is still outstanding and the run does not terminate. That is the same shape the defect has for a user, which is why it is worth saying rather than reporting a red assertion that does not exist.

Both cases run clean under ASan and under TSan, nine of nine with no sanitizer report.

The clang-tidy job counts warnings against a limit and main sits at it, so the scaffolding here had to stay out of that budget. It does: checked with CMAKE_CXX_CLANG_TIDY over the all-options-abiv1-preview cache file, the way the job runs it, the test file reports nothing and the one warning left in otlp_http_client.cc is the one main already has, moved down by the nine lines this adds.

This is an exporter-side correctness fix over the installed custom HttpClient interface. It does not change the curl implementation and does not pre-commit anything in the transport design discussed in #4448, which is where @lalitb noted it can proceed independently.

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 82.73%. Comparing base (1c2b007) to head (f5e17e2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4453      +/-   ##
==========================================
+ Coverage   82.67%   82.73%   +0.06%     
==========================================
  Files         516      516              
  Lines       20197    20197              
==========================================
+ Hits        16696    16708      +12     
+ Misses       3501     3489      -12     

Files with missing lines	Coverage Δ
exporters/otlp/src/otlp_http_client.cc	73.48% <ø> (+2.36%)	⬆️

🚀 New features to boost your workflow:

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