@jakelandis

I also don't have enough experience to advise on the quality or coverage of the tests.

It's tricky to asses the coverage when interfacing so closely with the netty code, as the API surface is large and not explicitly defined (it's only defined by the object types, and their order, as they flow through the pipeline from request decoding through aggregation).

This PR only covers a single case/observation: when there's a HTTP decoding error, a new FullHttpRequest is generated rather than a HttpRequest, as is normally the case.

So, the tests in Netty4HttpHeaderValidatorTests make sure to cover that the header validator works correctly with FullHttpRequests which might or might not have a decoding error attached. Working correctly in this case means that FullHttpRequests are validated just as HttpRequests are, including the case where there's a decoding error attached, in which case validation/authentication is not performed (because validation might choke on an invalid request and the request will be rejected irrespective of the validation outcome anyway - the test in Netty4HttpPipeliningHandlerTests).

The tests in SecurityNetty4HttpServerTransportTests are a sort of bonus ITs (more end-to-end). I've tested a couple of invalid request cases that should fail during decoding and ensured that validation is not invoked for those, while them being dispatched as bad requests (will return an error rather than execute the associated endpoint handler).