Decode a lone response body part in place

[pavel-ptashyts]

Problem

For the default handler (executeRequest(request) -> AsyncCompletionHandlerBase
-> Response) the body is copied three times:

1. HttpHandler.handleChunk -> EagerResponseBodyPart copies each chunk out of
   the network buffer into a heap byte[] (needed: channelRead releases the
   message afterwards);
2. NettyResponse.getResponseBodyAsByteBuffer concatenates every part into a
   freshly allocated array;
3. getResponseBody(charset) decodes that array.

Step 2 is pure waste when there is only one part, which is the case for any body
that lands in a single socket read: it copies a single part into a new array with
nothing to concatenate it with.

Change

getResponseBody(Charset) decodes straight from the part when there is exactly
one of them. The array does not escape the method, so the part's own array can be
decoded in place.

Several parts are still concatenated before decoding, never decoded one at a
time, because a multi-byte character can straddle a part boundary.

getResponseBodyAsBytes and getResponseBodyAsByteBuffer are deliberately left
untouched: they hand the array to the caller, so they keep making a defensive
copy rather than expose a part's own array. There is no aliasing change anywhere
in this PR.

Measurements

Rough probe on JDK 17 over a single-part ASCII body, concatenate-then-decode
versus decode-in-place. Not JMH, so read the shape rather than the digits:

body	before	after
512 B	496 ns	47 ns
4 KB	2277 ns	373 ns
16 KB	2963 ns	1450 ns
128 KB	24913 ns	12248 ns

Plus one fewer whole-body allocation per response. The percentages look large
partly because a pure-ASCII body decodes through a JDK intrinsic, which makes the
removed copy a big share of what is left.

Tests

Two added to NettyAsyncResponseTest:

• testGetResponseBodyDecodesOnePartAndSplitPartsIdentically splits the two-byte
  UTF-8 encoding of U+00E9 across two parts and asserts one-part and split-part
  bodies decode alike. This pins the constraint the comment states: it fails if
  anyone later makes the multi-part path decode part by part.
• testGetResponseBodyAsBytesDoesNotShareTheBodyPartArray pins that
  getResponseBodyAsBytes still returns a fresh array and never the part's own.

The body bytes are built as an explicit byte[] rather than a string literal to
keep the source ASCII per AGENTS.md.

Verification

mvnw clean verify - BUILD SUCCESS, 1373 tests (1371 before, plus these two),
0 failures, 0 errors, 19 skipped. Error Prone, NullAway and Revapi clean.
LargeResponseTest, NoNullResponseTest, BodyDeferringAsyncHandlerTest and
RedirectBodyTest, which exercise the multi-part path, are green.

Caveat on the testing gate: AGENTS.md requires the build to run on JDK 11 and
no JDK 11 is installed on this machine, so it was run on JDK 17 (also in the
CI matrix). The JDK 11 leg of CI on this PR is the real gate.

Not in scope

The multi-part case still concatenates. A CompositeByteBuf.toString(charset)
variant measured faster there (Netty decodes a multi-component buffer through a
recycled, un-zeroed thread-local array instead of a fresh byte[]), but it
regressed at high part counts in the same probe, so it needs proper benchmarking
before it becomes a change. Removing copy 1 would mean retaining network buffers
and giving Response a lifecycle, which is public API and wants a design
discussion first.

No public API change here. Same review pass as #2300, #2301 and #2302.

Claude Code on behalf of @pavel-ptashyts

🤖 Generated with Claude Code