[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

Four cases, all in otlp_http_exporter_custom_client_test.cc, driven by the existing nosend client. Three are a parameterised case, one per state: deliver it as the only terminal event and require the result callback to have run exactly once with kFailure, and ForceFlush with a 50 ms deadline to report success rather than wait. The fourth 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.

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