Server-side `AsyncContext` initialized in lifecycle observer is lost

[idelpivnitskiy]

Motivation:

If users put any data into AsyncContext inside HttpLifecycleObserver configured via HttpServerBuilder.lifecycleObserver(...) it won't be visible for filters and service because ClearAsyncContextHttpServiceFilter is appended after HttpLifecycleObserverServiceFilter inside applyInternalFilters.

Modifications:

1. Move ClearAsyncContextHttpServiceFilter from the beginning of noOffloadServiceFilters to applyInternalFilters. However, this move discovered another bug in path that handles noOffloadServiceFilters.isEmpty() case because it never adds OffloadingFilter.
2. Refactor listenForService method to always make a copy of filters lists, then prepend/append internal filters to those copies in easy to read/understand way, and construct a single filters Stream for buildService method.
3. Refactor OffloadingFilter to act as a regular filter factory instead of taking all further serviceFilters as pre-built factory.
4. Rename ClearAsyncContextHttpServiceFilter singleton instance.
5. Fix another bug when OptionalSslNegotiator binder takes a raw service instead of filteredService (user-defined filters were never applied for this path).
6. Modify AbstractHttpServiceAsyncContextTest to test AsyncContext propagation from lifecycle observer and non-offloading filters.
7. Modify AbstractHttpServiceAsyncContextTest to test AsyncContext initialized by early/late connection acceptor is not visible at request path.
8. Add BlockingHttpServiceAsyncContextTest and HttpServiceAsyncContextTest to make sure AsyncContext propagation for blocking/async aggregated services is also tested.
9. Use ParameterizedTest where possible.

Results:

1. AsyncContext initialized inside server's lifecycle observer is visible through filter chain and services.
2. Construction of server-side filter chain is consistent and sequential.
3. Filters are applied for servers with optional TLS.

[idelpivnitskiy]

just wanted to make sure that it is double checked that the new order is good and nothing ended up accidentally in the wrong spot of the filter chain. Doesn't look like it to me, just checking.

There are existing tests to validate most of the features and ordering:

• HttpServerFilterOrderTest to test the ordering of user-added filters;
• ServerEffectiveStrategyTest to test OffloadingFilter (it started to fail when I moved ClearAsyncContextHttpServiceFilter);
• AbstractHttpServiceAsyncContextTest to test ClearAsyncContextHttpServiceFilter;
• HttpLifecycleObserverTest to test observer;
• ConnectionCloseHeaderHandlingTest to test KeepAliveServiceFilter;
• There are plenty if tests with unhandled exceptions for HttpExceptionMapperServiceFilter;
• HttpMessageDiscardWatchdogServiceFilterTest (reenabled locally to test);