This commit add mock support for WebFlux with an infrastructure similar
to what `WebMvcTest` provides. `@WebFluxTest` can be used to test
controllers with a narrowed classpath that is relevant to WebFlux. Also,
`@SpringBootTest` now starts WebFlux in "mock" mode by default and
`@AutoConfigureWebTestClient` can be used to inject a `WebTestClient`
connected to the `ApplicationContext`.

To make that happen, a `ReactiveWebApplicationContext` interface has been
introduced to mirror what `WebApplicationContext` currently does. Things
are still a bit volatile at this point and that infra may move to Spring
Framework at some point.

Closes gh-8401

Closes gh-8412

Closes gh-8403

The server's session can now be configured in both a servlet and a
reactive environment. The latter has not requirement on the servlet API
and this commit removes the requirement to the `SessionTrackingMode`
enum.

Closes gh-8402

Reactor Netty and Spring WebFlux were missing.

This commit exposes a `WebTestClient` automatically in a reactive
integration test that uses an embedded web server. This is similar to
what we do with `TestRestTemplate` for servlet based integration tests.

Closes gh-8399

This commit adds a sample application for the
annotation variant of Spring WebFlux.

This commit makes sure that `@SpringBootTest` with a reactive setup
starts a web application if necessary.

If both a servlet and a reactive environment are available, a servlet
environment is bootstraped. This commit also adds a way to force a
reactive environment by specifying the `spring.main.web-application-type`
property of the test (e.g. `@TestPropertySource`).

Closes gh-8383

This commit creates auto-configuration classes for both the
annotation and functional variants of the WebFlux framework.

They provide the basic support to get started with those, by
creating the required `HttpHandler` using the provided application
context (for annotation) or `RouterFunction`s (for functional).

They do support `WebFilter` registration and a few advanced
features such as resource handling, `messageReaders|Writers`
and `ViewResolver` auto-registration.

Closes gh-8386

This commit adds the auto-configuration for creating reactive
`EmbeddedWebServer` instances. This adds support for the
following servers: Reactor Netty, Tomcat, Jetty and Undertow.

Fixes gh-8302
Fixes gh-8117

This commit refactors the `EmbeddedWebServerInitializedEvent` hierarchy
to have one specialized event for Servlet based apps and another one for
reactive apps.

Each event implementation has:

* a specific `ApplicationContext` implementation for the app
* a custom `getServerId` implementation that differentiates the
application server from the management server

Closes gh-8348

This commit adds an `EmbeddedWebServer` instance to the
`ReactiveWebApplicationContext` and ties it to the application
lifecycle.

To launch a reactive web application, two elements are required
from the context:

* a `ReactiveWebServerFactory` to create a server instance
* a `HttpHandler` instance to handle HTTP requests

Closes gh-8337

This commit adds the infrastructure for creating and customizing
reactive embedded web servers. Common configuration has been refactored
into the new `ConfigurableEmbeddedWebServer` interface.

See gh-8302

This commit makes sure that the Spring `Validator` used by the MVC
layer doesn't expose a JSR-303 contract, if any.

The default implementation of the `mvcValidator` is
`LocalValidatorFactoryBean`. While this object is exposed as a Spring
`Validator` only, its runtime capabilities expose that contract as well
as the standard `Validator` and `ValidatorFactory` ones.

Concretely, if an auto-configuration is checking if a
`javax.validation.Validator` bean is missing, the condition will match
since we only know about "advertized types": beans haven't been created
yet so we can't inspect their runtime capabilities. Since the condition
match, we will auto-configure a bean. At runtime though, we're no longer
ale to inject a `javax.validation.Validator` by type since two candidates
are available.

This commit introduces `SpringValidatorAdapterWrapper`, a wrapper class
on any `SpringValidatorAdapter` (`LocalValidatorFactoryBean` being one of
the available implementations) that only exposes the Spring contract.

Also, if a `javax.validation.Validator` bean is available, we will use it
for the MVC layer, rather than creating a new one.

Closes gh-8223

See gh-8382

See gh-8379

Closes gh-7896

Closes gh-7232

It used to be pulled in transitively by selenium-api but that's no
longer that case.

See gh-8381

Closes gh-8382

Closes gh-8381

Closes gh-8380

Closes gh-8379

Closes gh-8378

Closes gh-8377

Closes gh-8376

Closes gh-8375

Closes gh-8374

Closes gh-8373

Closes gh-8372

Closes gh-8371

Closes gh-8370

Closes gh-8369

Closes gh-8368