Issue: SPR-13965

Issue: SPR-14780

Issue: SPR-8282

Issue: SPR-14791

This commit replaces direct use of Validator and ConversionService in
the reactive @RequestMapping infrustructure in favor of using the
BindingContext.

Issue: SPR-14541

This commit adds a BindingContext to be used in spring-web-reactive
@RequestMapping infrastructure (comparable to WebDataBinderFactory in
spring-web-mvc) for access to the default model, data binding,
validation, and type conversion purposes.

Issue: SPR-14541

Issue: SPR-14541

Prior to this commit, PrintingResultHandler always printed the request
or response body regardless of its content type. For binary content,
however, the output was unreadable and therefore useless.

This commit addresses this issue by only printing the request or
response body if it is "printable" (i.e., if its content type is known
to be text-based such as plain text, HTML, XHTML, XML, JSON, etc.). If
the content type is unknown (e.g., unspecified for the HTTP request in
the test), it is assumed that the body is printable.

Issue: SPR-14776

This commit adapts the fix for SPR-14597 commited to spring-webmvc to
the spring-web-reactive module.

Issue: SPR-14597

Prior to this commit, `ResourceTransformer` implementations would
resolve internal links to other resources: both relative and absolute
request paths.
For relative request paths, those transformers would call
`ResourceTransformerSupport.resolveUrlPath` with the resource path,
as provided in the original file. This can cause problems when a
`CachingResourceResolver` is configured in the resolver chain, because
this resolver is caching resources, deriving the cache key from the
given resource path — this can cause collisions for cases like this:

    resources/
    |--foo/
    |  |--foo.css (imports style.css)
    |  |--style.css
    |--bar/
    |  |--bar.css (imports style.css)
    |  |--style.css

The first "style.css" resolved resource is then cached and will be given
to any request asking for "style.css".

To avoid those issues, this commit improves the `ResourceTransformer`
implementations to calculate the absolute request path before asking the
chain to resolve the resource URL, thus avoiding duplications.
The resource chain will be then asked to resolve "/foo/style/css" or
"/bar/style.css".

Issue: SPR-14597

Issue: SPR-14792

Issue: SPR-14793

This is a port of Spring MVC CORS support for Spring Web Reactive:
 - CORS classes keep the same name but are in the
   web.cors.reactive package
 - CorsConfiguration is reused because not tied to Servlet API
 - CORS HandlerMapping integration is done at
   AbstractHandlerMapping level
 - AbstractUrlHandlerMapping and AbstractHandlerMethodMapping
   have been slightly modified to call
   AbstractHandlerMapping#processCorsRequest()
 - Both global CORS configuration + @CrossOrigin support have
   been implemented

Issue: SPR-14545

Host and port are now properly retrieved from Reactor
Netty and RxNetty (the scheme is not available).

Issue: SPR-14794

This commit fixes `NumberFormatException`s that were thrown when parsing
IPv6 host values in `X-Forwarded-Host` request headers.

Issue: SPR-14761

This commit configures a default SslContext if none has been provided.
This also enforces separate Netty bootstrap instances for cleartext and
TLS exchanges.

Issue: SPR-14744

This new Reactor Netty release fix a critical issue that could
prevent proper connection handling.

Issue: SPR-14778

Explicit calls on Buffer base type (for compatibility with covariant return type on JDK 9's ByteBuffer)

Issue: SPR-14645

Issue: SPR-14765

Issue: SPR-14743

Prior to this commit, the `HttpEntityMethodProcessor` would avoid
writing ETag/Last-Modified response headers before calling
`ServletWebRequest` to process conditional requests. This was done to
avoid duplicate response header values due to headers being already
written to the underlying servlet response.

This is still necessary for GET/HEAD requests, since this is properly
handled by `ServletWebRequest` for those cases. But
`HttpEntityMethodProcessor` should not make that decision for
PUT/PATCH/POST responses since developers are adding response headers on
purpose and should be in control of the situation — whereas
`ServletWebRequest` does not write those headers in those cases.

Issue: SPR-14767

Prior to this commit, the PrintingResultHandler used by the various
print() and log() methods in Spring MVC Test printed the response body
but not the request body.

Since request bodies are sometimes generated programmatically, however,
it can be beneficial to have the dynamically generated request body
logged as well.

This commit therefore prints the request body in PrintingResultHandler
by delegating to the recently introduced getContentAsString() method in
MockHttpServletRequest.

Issue: SPR-14717

In order to improve debugging and logging within test suites, this
commit introduces getContentAsByteArray() and getContentAsString()
methods in MockHttpServletRequest, analogous to the existing methods in
MockHttpServletResponse.

Issue: SPR-14717

This commit refine Jackson canEncode() / canDecode()
implementation by using ObjectMapper canSerialize() /
canDeserialize() methods.

Issue: SPR-14748

Issue: SPR-14748

Issue: SPR-14748