Upgrade to AHC 3.0.15 and decide streamed-body resumes through ResponseBodyControl.execute

[mkurz]

• Follow-up to Upgrade to AsyncHttpClient 3.0.14 #1481 and Support HTTP/2 over HTTPS and apply the configured TLS settings #1483.
• Draft until AsyncHttpClient releases these changes. project/Dependencies.scala already asks for AHC 3.0.15, so CI cannot pass before that release.

This builds on these AsyncHttpClient pull requests:

• feat: add ResponseBodyControl.execute to decide in sequence with body delivery AsyncHttpClient/async-http-client#2359
• fix(netty): keep caller Cookie headers as written on redirects and auth retries AsyncHttpClient/async-http-client#2360
• fix(netty): never let a queued suspend override a later resume AsyncHttpClient/async-http-client#2361
• fix(netty): stop inflating a suspended HTTP/1.1 response AsyncHttpClient/async-http-client#2362

The first commit needs AsyncHttpClient/async-http-client#2359. Each other commit needs one of the other three and is dropped if that one misses the release:

• the cookie commit needs fix(netty): keep caller Cookie headers as written on redirects and auth retries AsyncHttpClient/async-http-client#2360;
• the decompression commit needs fix(netty): stop inflating a suspended HTTP/1.1 response AsyncHttpClient/async-http-client#2362;
• the commit about suspending on the event loop needs fix(netty): never let a queued suspend override a later resume AsyncHttpClient/async-http-client#2361.

Related, but not needed for this PR:

• HTTP/2: Respect read limits for frames queued at end of stream netty/netty#17774

It is a prerequisite for bounding HTTP/2 decompression in a later AHC change; AHC would still have to handle the output left from the final DATA frame. Until then, the README's HTTP/2 caveat in the maxDecompressedResponseSize section stays.

Play WS now re-checks its resume decisions through AHC's new public ResponseBodyControl.execute instead of reaching AHC's event loop through Netty's internal ThreadExecutorMap. It also documents two AHC changes that Play WS users can see.

Streamed-body resumes

ResponseBodyPublisher resumes transport reads when the subscriber has demand and nothing is buffered. A resume() from a subscriber thread only takes effect later on the event loop, after parts that the loop may still be decoding. Since #1481, Play WS has prevented that stale resume by capturing the event loop with ThreadExecutorMap.currentExecutor() and re-running the check there. ThreadExecutorMap is internal to Netty.

AHC 3.0.15 adds ResponseBodyControl.execute(Runnable), which runs a task on the event loop that delivers the response body, in sequence with the callbacks made there: inline when called on that event loop, queued to it from any other thread. Play WS now passes its check to execute:

• If the task runs on the thread that asked for it, that is, inline on the event loop or with a control that applies calls synchronously, it resumes directly. The drain() that asked has just decided on the current state.
• If it runs on the event loop after being queued from another thread, it runs one more drain() pass there, which resumes only if demand is still unmet.
• As before, at most one queued check is pending at a time.

There is no behavior change for users. The existing tests for lost resumes, stale resumes and on-loop suspension still pass; only their fake controls changed, to model execute.

Play WS keeps suspending only on the event loop, so each suspension takes effect before the next body part. Before AHC 3.0.15, that was also needed because a suspend queued from another thread could undo a newer resume and stall the stream; AHC 3.0.15 skips such a suspend. A separate commit updates the comment and the spec's description; the code is unchanged.

AHC changes visible to Play WS users

• Raw Cookie headers with play.ws.ahc.useCookieStore = true: redirects and authentication retries now keep the header as written, except for pairs whose cookie a response replaced or deleted. Before, they re-encoded it: pairs could be reordered, valueless or unbalanced-quote pairs were dropped, and a value that AHC's strict encoder rejected failed the redirect or retry. A new redirect test pins this.
• Compressed HTTP/1.1 streams: AHC now hands on decompressed HTTP/1.1 body parts of at most 64 KiB and pauses decompression while the stream has no unmet demand, apart from one decompressor buffer of look-ahead. Before, every socket read of up to 64 KiB was inflated and delivered in full, so a highly compressible body could queue tens of MiB beyond demand. When the connection closes, what was already received is still decompressed at once. HTTP/2 is unchanged. The README's maxDecompressedResponseSize section is updated, and StreamedGzipBufferingSpec now asserts that nothing is delivered beyond demand. It measures delivered parts, not memory inside the decompressor.

Before marking ready

• An AHC release contains feat: add ResponseBodyControl.execute to decide in sequence with body delivery AsyncHttpClient/async-http-client#2359. If it isn't called 3.0.15, update the version and the README's version mentions.
• Drop the commits whose AHC pull request is not in that release (see above).
• Check nettyVersion in project/Dependencies.scala against the Netty version of that AHC release. Play WS main is on 4.2.19.Final since netty-buffer, netty-codec-base, ... 4.2.19.Final (was 4.2.18.Final) #1484, while AHC still pins 4.2.18.Final.
• Re-check the README's "With AHC 3.0.15, a TLS connection to a proxy of type HTTPS also offers h2" paragraph against Plans for the fix/proxy-hop-alpn branch AsyncHttpClient/async-http-client#2358.

Test plan

Local runs, on JDK 17 unless stated otherwise, with a temporary local commit (not part of this PR) that resolves AHC from a local snapshot. CI cannot run before the AHC release.

Against a local AHC build that merges all four AHC pull requests (1,853 AHC tests pass):

• sbt validateCode.
• Scala 2.13: play-ahc-ws-standalone/testFull and integration-tests/testFull, 18 and 17 test classes, all pass, none served from the test cache. MiMa passes.
• Scala 3.3.8, with a fresh sbt server, compiled to scala-3.3.8: the same suites pass.
• StreamedGzipBufferingSpec: 0 bytes delivered beyond demand in each of its three runs.
• The shaded AHC jar contains AHC's new decompressor, including its part splitting, and Netty's pull decompressors, and no unshaded classes.
• After rebasing onto main with Netty 4.2.19 (netty-buffer, netty-codec-base, ... 4.2.19.Final (was 4.2.18.Final) #1484): validateCode, both suites on Scala 2.13 and 3.3.8, and MiMa pass.

Against the previous revision of the AHC changes, which differed only in the decompressor's multi-member gzip support and part splitting, and in Javadoc and tests:

• JDK 21 and JDK 25, Scala 2.13: both suites pass.
• Scala 2.13: doc passes.
• Local stress specs (from a local-only branch, not part of this PR): ResponseBodyPublisherStressSpec, 3,000 iterations, 0 stalls; StreamingStallStressSpec, 300 HTTP/1.1 and 300 HTTP/2 iterations with mixed consumers, 0 stalls and 0 wrong sizes.

Against a local AHC build of AsyncHttpClient/async-http-client#2359 alone (Scala 2.13, before the decompression commit):

• All tests pass, except the new cookie test, which needs fix(netty): keep caller Cookie headers as written on redirects and auth retries AsyncHttpClient/async-http-client#2360: the valueless flag pair is dropped.
• StreamedGzipBufferingSpec, with its earlier bound of 10 MiB: 1,875,916 bytes beyond demand, the same as with the ThreadExecutorMap workaround. With Play WS resuming directly instead of through execute, 35,589,292 bytes, and the test fails.

The decompression commit's bound of 0 bytes holds only with AHC's demand-bounded decompression.