Improve HTTP validation for inlining and specialized types

[franz1981]

This change is mostly to improve native-image performance on validation due to closed-world assumption which lead to virtual calls while reading the chars to validate and no loop unrolling during validation.

Additionally, it takes care of moving out of the hot path unlikely validation scenarios for http header values e.g. presence of CRLF or non-printable control chars: this should help JVM mode as well.
Another thing which can help, despite the duplicated code, is the specialized latin head name validation because doesn't require to turn byte into chars for AsciiString.
Without this change the validation of ASCII heard names was slower than normal strings!
FYI @galderz

[franz1981]

I've had some fun with assembly and reading the RFC and I'm going to push a major improvement on this, turning this in draft first

[franz1981]

TLDR

1. I've streamlined the header name common path (according to the RFC, which is way stricter!)
2. I've retained the original behaviour, with some improvement without duplicating any logic as it is fine to be slower there

I think that I could have further exploded the original state machine and let the hotspot JVM to do it right (if able!), but sadly native image isn't that smart and I prefer to keep it like this as it looks more like what Netty do, but with a less strict fallback.

Performance on Hotspot look great, compare to what it was (I will post something home back to my desk), while I can wait @galderz to valide this (I have added a benchmark on purpose, which could be reused) on native image - 🤞

[franz1981]

I have pushed e4f4342 and verified it holds from jdk 17 to main.

It solves a problem of "untrusted" types like AsciiString: since the JVM cannot trust offset and end vs arrays boundaries, it would perform additional computations to perform bound checks.
Giving the JIT an hints that offset is 0 (JIT can profile branches) allow propagating that information, reducing some of these computations in the compiled unrolled version of the loop.
I didn't verify if the same problem happens on end too, since I couldn't spot any weird bookkeeping after this change, although I am sure there is much more to shave.
I would like to produce a code which is less magic 🪄 and still do the right thing.

This explain both why Strings are better performers and why Netty value validation was faster: due to a bug of the Netty version (I will send a pr to fix it, since it looks like a potential security issue) the loop variables trigger a better JVM optimization.

[franz1981]

Any chance you looked into the code @vietj ?

[vietj]

early next week @franz1981

[vietj]

scheduled for 4.5.12 @franz1981