Motivation:

The goal of this PR is to fix a character validation bypass in
HttpUtil.validateToken.

Prior to this change, the validateCharSequenceToken method was
susceptible to "high-order bit aliasing." Because the logic performed a
direct cast from a 16-bit char to an 8-bit byte, any Unicode character
whose lower 8 bits matched a valid RFC 7230 tchar would be incorrectly
validated.

For example, the character 'Š' (U+0161) has the bit pattern 00000001
01100001. A narrow cast to byte strips the high-order bits, leaving
01100001, which is the ASCII value for 'a'. Since 'a' is a valid token
character, the validator would return -1 (valid), violating the
strictness required by RFC 7230.

Modification:

* Modified validateCharSequenceToken(CharSequence token) to store the
character in an int variable to prevent multiple charAt lookups and
maintain consistency with Netty's internal coding style.
* Introduced an explicit range check (value > 0xFF) to catch high-order
characters before they are cast to byte.
* Updated HttpUtilTest with a new parameterized test
testInvalidTokenCharsHighOrderBitAliasing that specifically tests
Unicode characters known to alias into the valid tchar range (U+0161,
U+0121, U+0231, U+0361).

Result:

This change ensures that HttpUtil correctly rejects non-ASCII and
multi-byte characters that were previously able to bypass the token
validation logic.

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
(cherry picked from commit 95cc055)