Route processing refactor

[yawkat]

This is a refactor of route execution, excluding filters (those will follow in #8422). The goals are:

• Moving away from reactive APIs where possible.
• Streamlining route execution so that it will be possible to have pre-route filters, and filters that read the request body.

This initial patch factors most of the routing code out of RoutingInboundHandler (the response writing code remains), and moves away from reactive for HttpContentProcessor and the route parameter fulfillment code (now called BaseRouteCompleter and FormRouteCompleter).

The goal of this PR is to get to a point where I am confident that it will be easy to delay filter execution until the body is available. Ideally the full request lifecycle, from before route resolution, through filter execution, to route execution, will be contained in the RouteRunner class.

edit, For reviewers: Much of the RouteExecutor code was moved to RequestLifecycle. Much of the RoutingInboundHandler code was moved to NettyRequestLifecycle and the two completer classes. Additionally, there is a new MicronautHttpData class that replaces netty's HttpData implementation, and HttpContentProcessor was refactored to not be reactive, which helps avoid concurrency considerations.

[yawkat]

jackson-xml pr to fix up content processor: micronaut-projects/micronaut-jackson-xml#235

[yawkat]

servlet pr to fix up RouteExecutor dependency: micronaut-projects/micronaut-servlet#363

[yawkat]

This PR is now ready. The request routing code is now concentrated in RequestLifecycle. This should make it much easier to implement additional filtering behavior, such as reading the request body.

[yawkat]

micronaut-projects/micronaut-aws#1527

[yawkat]

In the AWS module, I've replaced most of the custom request processing code with the existing code in RouteExecutor. They are mostly the same, but there are a few differences.

The biggest change is about uses of request.getUri().toString(). For netty requests, this is usually identical to the path of the request. However with the aws proxy module, it includes the request host, so any route processing that treats the uri as a path breaks.

I've adjusted a few of these use sites related to route selection to use request.getPath() in 4a040af and 686de0f.

[dstepanov]

I think we need to have more changes done if we want to support reading the request body in the pre-route filters. Probably introducing some internal structure that can represent the request body in different stages (fetched, reactive fetching) and different body contents (JSON, Form etc). That would likely eliminate receivedContent and receivedData from the NettyHttpRequest.

[yawkat]

@dstepanov yes more changes are needed. but i think they can be limited to RequestLifecycle and NettyRequestLifecycle now. All previous users of RouteExecutor (netty, netty websocket, jetty, aws) now use RL, and e.g. filter processing is encapsulated (no more calls to filterPublisher), so it should be possible to limit changes to RL.

However this PR is too big already. It will be in follow-up PRs.

[dstepanov]

Going to approve it as nothing is blocking it. I feel like classes like HttpContentProcessorAsReactiveProcessor FormRouteCompleter StreamingDataSubscriber are a bit complex and hard to understand. Maybe we can revisit it after we have all the changes that are needed for Microanut 4.

[yawkat]

im still testing some changes for your other comments, so please don't merge yet :)

[yawkat]

@graemerocher just finished it, all comments from @dstepanov addressed

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

85.7% Coverage
0.0% Duplication