Fix HTTP/2 cancellation during stream creation

[ittaigolde]

Summary

Fix HTTP/2 call cancellation when a call is blocked creating a new stream and flushing request headers.

When Http2ExchangeCodec.writeRequestHeaders() calls Http2Connection.newStream(), the new stream is not assigned to the codec until newStream() returns. If the underlying HTTP/2 writer blocks during that operation, Http2ExchangeCodec.cancel() currently only sets canceled = true; there is no stream reference yet, so it cannot send RST_STREAM or interrupt the blocked writer.

This means an overall callTimeout can fire, RealCall.cancel() can reach the codec, but the thread doing the HTTP/2 write can remain blocked in socket I/O.

This patch tracks when stream creation is in flight. If cancellation happens in that window before a stream is available to close, the codec cancels the underlying HTTP/2 connection socket to interrupt the blocked writer. Once a stream exists, cancellation continues to use the narrower stream-level closeLater(CANCEL) behavior.

Fixes #8014

Verification

Added Http2ConnectionTest.cancelHttp2ExchangeInterruptsBlockedStreamCreation, which uses a fake BufferedSocket whose sink blocks on flush().

The regression exercises the existing Http2ExchangeCodec.cancel() path:

• Before the production fix, the test reproduces the bug: codec.cancel() does not unblock writeRequestHeaders(), and the test fails because the writer thread does not complete within the timeout.
• With the fix, codec.cancel() interrupts the blocked stream creation and the test completes with an IOException.

Commands run:

./gradlew :okhttp:jvmTest --tests okhttp3.internal.http2.Http2ConnectionTest.cancelHttp2ExchangeInterruptsBlockedStreamCreation
./gradlew :okhttp:jvmTest --tests okhttp3.internal.http2.Http2ConnectionTest

Both pass with the fix applied.

Debugging Notes

Static analysis showed the cancellation gap in the Http2ExchangeCodec.writeRequestHeaders() -> Http2Connection.newStream() path: the stream can exist inside Http2Connection, while the codec still has stream == null until header write/flush returns.

We also verified the repro/fix behavior using the local JDWP debugging workflow with debug-bridge / java-debug-mcp:

https://github.com/ittaigolde/java-debug-mcp

[ittaigolde]

The failing build / testwindows job looks unrelated to this PR.

It failed in HttpOverHttp2Test_HTTP_2[jvm] > connectionWithTwoRefusedStreamsIsNotPooled() with StreamResetException: stream was reset: REFUSED_STREAM. The PR changes cancellation while HTTP/2 stream creation is blocked before a stream exists; this test fails after a stream already exists and goes through the existing retry/cleanup path.

I checked the exact CI merge ref locally:

• :okhttp:jvmTest --tests okhttp3.internal.http2.HttpOverHttp2Test.connectionWithTwoRefusedStreamsIsNotPooled passed
• a temporary local @RepeatedTest(100) run of the same test also passed 100/100

Could someone rerun the failed build / testwindows job?

[yschimke]

This method feels awkward given we have other close methods, it's really socket.cancel, but it feels like codec and connection are too coupled if we need this hammer from codec to connection.

[yschimke]

Rather than this new http2Connection cancel, can we use Carrier?

    carrier.noNewExchanges()
    carrier.cancel()