Skip redirect set lookup for non-3xx responses

[pavel-ptashyts]

Problem

Interceptors.exitAfterIntercept runs for every HTTP response and tested the
redirect status like this:

if (Redirect30xInterceptor.REDIRECT_STATUSES.contains(statusCode)) {

REDIRECT_STATUSES is a Set<Integer> and statusCode is an int, so the
call autoboxes. Integer.valueOf caches -128..127, which covers 100..103 but
nothing else a response carries, so every 2xx / 4xx / 5xx response allocated a
fresh Integer and hashed it, only to answer false. Those are almost all of
the traffic.

Change

Move the test into a package-private Redirect30xInterceptor.isRedirect(int),
next to the set it guards, and gate the set lookup behind Netty's
HttpStatusClass.REDIRECTION.contains(int). That check takes a primitive, so
only a genuine 3xx pays for the boxing.

The set is still consulted rather than inlined as a switch over the five
known codes. REDIRECT_STATUSES is public and a mutable HashSet; changing
what it means is out of scope for a performance change, so any 3xx a caller
registered keeps working. Behaviour differs only for a non-3xx code added to
the set, which would not be a redirect status.

No public API change.

Scope

One predicate, its two call sites, and a unit test. Related per-response
allocations found in the same method (responseHeaders.getAll(SET_COOKIE)
allocates a LinkedList per response even with no Set-Cookie present) are
left for a separate PR.

Tests

Redirect30xInterceptorTest covers isRedirect(int) directly: the five
followed statuses, the 3xx that are not followed (300, 304, 305, 306, 399 -
304 above all, which must reach the normal response path), and non-3xx codes.

The redirect paths themselves are already covered by Relative302Test,
PerRequestRelative302Test, PostRedirectGetTest, RedirectBodyTest,
HttpToHttpsRedirectTest, RedirectCredentialSecurityTest,
RedirectConnectionUsageTest, Head302Test,
StripAuthorizationOnRedirectHttpTest and ws.RedirectTest.

Verification

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.

Follows the same review pass as #2300.

Claude Code on behalf of @pavel-ptashyts

🤖 Generated with Claude Code

[hyperxpro]

Can we drop this one? It describes the change rather than the code, and once the old version is out of memory it just reads as noise. It is also four lines of prose for a one line predicate, where the rest of the file only comments invariants. If you want something here, one line does it: only a 3xx can be a redirect, so the range check keeps the boxed lookup off the common path.

[pavel-ptashyts]

Dropped. It was describing the change rather than the code, and with the predicate moved into Redirect30xInterceptor the call site reads on its own, so there is nothing left worth saying there.

[hyperxpro]

Netty already has this one. HttpStatusClass.REDIRECTION.contains(statusCode) takes an int and uses the same 300/400 bounds. We do not use HttpStatusClass anywhere else yet, so take it or leave it, the explicit range reads fine.

[pavel-ptashyts]

Taken. REDIRECTION is built with 300/400 bounds and contains takes an int, so it keeps the boxing off non-3xx responses exactly as the open-coded range did, and it names what the bounds mean instead of leaving two magic numbers. First use of HttpStatusClass in the codebase, but that seems like a reason to start rather than not to.

[hyperxpro]

Minor: the range now lives here while the set lives in Redirect30xInterceptor, so the knowledge is split across two classes. A static isRedirect(int) next to the set would keep it in one place and give you something to test. Fine to skip if you want the diff minimal.

[pavel-ptashyts]

Done. Package-private isRedirect(int) next to the set, so Interceptors just asks the question and the range and the statuses stay together.

Added Redirect30xInterceptorTest for it. The case that earns the test is 304: in the 3xx class, not a followed redirect, so it has to be rejected exactly like a non-3xx status. Neither half of the predicate says that on its own.