micronaut-core One channel per HTTP2 stream

This PR refactors the NettyHttpServer to have a more straight-forward pipeline setup in a separate class (HttpPipelineBuilder), and then uses netty's Http2MultiplexHandler to multiplex each HTTP2 stream from one connection to its own Channel.

Multiplexing improves compatibility with HTTP 1 handlers downstream. While HTTP 1 handlers do not need to be aware of multiple concurrent request or response streams, HTTP 2 handlers do. With multiplexing, the HTTP 1 handlers only manage one HTTP 2 stream each, so concurrent requests are not an issue anymore.

This change prevents a class of bugs related to faulty STREAM_ID handling, such as #6785. It also adds a new feature, concurrent streaming responses (tested in this PR by Http2ConcurrentStreamSpec).

While all tests pass, this is a bit of a risky change. We expose a lot of the handler pipeline to downstream users, and this PR changes that pipeline fundamentally. For example, the SslHandler isn't visible on the pipeline anymore, which might lead downstream code to think SSL is disabled (this caused the test failure fixed in c9456e27c6828d4c371e5ab18d7fdaed60c29934). It's possible that there are similar downstream dependencies on the structure of the pipeline in other modules. This is why I'm making this PR to 3.4.x, so that we can see any issues as early as possible.

Jan 31 '22 10:01 yawkat

for review: it may be easier to look at 4013917e608b911503685623d3ae59124b463b8b as its own change, it does most of the refactoring of the HTTP pipeline setup. The subsequent commits change the pipeline setup for the multiplexing.

Jan 31 '22 10:01 yawkat

SonarCloud Quality Gate failed.