Instead of accepting List<Encoder|Decoder> and then look for the first
to support JSON, always expect a single JSON [Encoder|Decoder] and use
that unconditionally.

When writing use the nested ResolvableType instead of the Class of the
actual value which should better support generics.

Remove the SSE hint and pass "text/event-stream" as the media type
instead to serve as a hint. We are expecting a JSON encoder and using
it unconditionally in any case so this should be good enough.

Consolidate JsonView hint extraction in shared base class.

Rename base class from AbstractJackson2Codec to Jackson2CodecSupport
since the class mainly provides support methods.

ServerHttpMessage[Reader|Writer] are now expected for WebFlux,
annotated controller endpoint and subsequently the instanceof checks
for HttpMessage[Reader|Writer] vs ServerHttpMessage[Reader|Writer] can
be removed from AbstractMessageReaderArgumentResolver and
AbtractMessageWriterResultHandler.

Support for flushing in EncoderHttpMessageWriter is now driven from a
configurable list of "streaming" media types with the list including
"application/stream+json" by default.

As a result Jackson2ServerHttpMessageWriter is no longer needed.

ServerHttpEncoder and ServerHttpDecoder are HTTP-specific
specializations that can prepare encoding and decoding hints from
extra information available on the server side.

As a result Jackson2ServerHttpMessageReader is no longer needed.

There is a natural way to implement ServerHttpMessage[Reader|Writer]
from [Encoder|Decoder]HttpMessageWriter by resolving hints first via
a protected method and then delegating to the regular read or write.

There is no downside either since it does not prevent
[Encoder|Decoder]HttpMessageWriter from being used for both client and
server scenarios while they're more useful.

As a positive side effect AbstractServerHttpMessage[Reader|Writer] can
be removed further simplfications can be made (in a future commit) to
accept ServerHttpMessageWriter for configuration purposes on the server
side and remove instanceof checks for ServerHttpMessageWriter.

This commit changes the `MockServletContext.getMimeType` method to use
`MediaTypeFactory` instead of JAF. It also adds a `addMimeType(String,
MediaType)` method to customize the mime types returned from said
method.

Issue: SPR-14908

This commit updates the test code base to conform to changes in media
types returned by the MediaTypeFactory.

Issue: SPR-14908

This commit updates the main code base to conform to the dropped JAF
dependency in MediaTypeFactory. Specifically, it

 - Removes JAF detection (JAF_PRESENT constants)
 - Deprecated useJaf properties, with no direct replacement.
 - Updated docs to remove JAF references, in favor of MediaTypeFactory.

Issue: SPR-14908

This commit drops the Java Activation Framework dependency from the
MediaTypeFactory, in favor of parsing our own `mime.types` file, which
was obtained from Apache HTTPD.

Issue: SPR-14908

Fold ResourceRegionHttpMessageWriter into ResourceHttpMessageWriter.
The latter was a private helper (not meant to be exposed) and the two
have much in common now sharing a number of private helper methods.

The combined class does not extend AbstractServerHttpMessageConverter
from which it was not using anything.

Internally the combined class now delegates directly to ResourceEncoder
or ResourceRegionEncoder as needed. The former is no longer wrapped
with EncoderHttpMessageWriter which is not required since "resource"
MediaType determination is a bit different.

The consolidation makes it easy to see the entire algorithm in one
place especially for server side rendering (and HTTP ranges). It
also allows for consistent determination of the "resource" MediaType
via MediaTypeFactory for all use cases.

Due to a type inference bug in Eclipse, an additional “hint” is
required in order for RouterFunctionsTests to compile in Eclipse.

ResourceRegionHttpMessageWriter no longer extends from
EncoderHttpMessageWriter freeing it to pass the correct content type
into the encoder.

Considering that the main benefit of EncoderHttpMessageWriter is to
deal with content type fallback cases, there is nothing to be missed.

Furthermore ResourceRegionHttpMessageWriter is a package private class
that is used internally within ResourceHttpMessageWriter and never
exposed externally as a an actual HttpMessageWriter.

Issue: SPR-15358

EncoderHttpMessageWriter now consistently uses the same MediaType to
set on the response and to pass to the encoder.

Issue: SPR-15357

When CodecHttpMessageConverter was split into DecoderHttpMessageReader
and EncoderHttpMessageWriter the null checks were never removed.

This commit makes the Encoder and Decoder instances provided to their
respective wrappers required.

This commit adds support for the ResponseStatusException in the
`ServerResponse.writeTo` method.

Issue: SPR-15344

Issue: SPR-15307

Issue: SPR-15349

Issue: SPR-15348

Also revises copyToByteArray/String in FileCopyUtils/StreamUtils for lenient null handling.

Issue: SPR-15329

Issue: SPR-15332

Issue: SPR-15350

Issue: SPR-15350

This commit fixed the exception that occurs when a larger file is
transfered using zero-copy on Undertow.

Issue: SPR-15343

This commit introduces support for the ResponseStatusException in the
functional web framework.

Issue: SPR-15344

ExchangeMutatorWebFilter now supports multiple mutator registrations
for the same request header id by creating a single composed function.

Issue: SPR-15250

CompositeHttpHandler is public and called ContextPathCompositeHandler.

Also an overhaul of the Javadoc on HttpHandler, WebHttpHandlerAdapter,
and ContextPathCompositeHandler.