Issue: SPR-15354

Issue: SPR-15363

Issue: SPR-15375

Issue: SPR-15377

Issue: SPR-15257

Follow-up to:
https://github.com/spring-projects/spring-framework/commit/3d68c496f15c80a75711480a569cda1f7c64dc91

StringDecoder can be created in text-only vs "*/*" mode which in turn
allows a more intuitive order of client side decoders, e.g. SSE does
not have to be ahead of StringDecoder.

The commit also explicitly disables String from the supported types in
Jackson2Decoder leaving it to the StringDecoder in "*/*" mode which
comes after. This does not change the current arrangement since the
the StringDecoder ahead having "*/*" picks up JSON content just the
same.

From a broader perspective this change allows any decoder to deal with
String if it wants to after examining the content type be it the SSE
or another, custom decoder. For Jackson there is very little value in
decoding to String which works only if the output contains a single
JSON string but will fail to parse anything else (JSON object/array)
while StringDecoder in "*/*" mode will not fail.

Issue: SPR-15374

This commit introduces a `useRegisteredExtensionsOnly` property that
indicates whether classes that use the `MediaTypeFactory` for supplying
default media types can do so.

 - In classes that were introduced in Spring 5.0, the
 `useRegisteredExtensionsOnly` property takes the place of the
 `useJaf` property that was removed in 0aaa6528
 - In classes that existed before Spring 5.0, the
 `useRegisteredExtensionsOnly` property is added in addition to the
 deprecated `useJaf`, the latter delegating to the former, but with
 flipped behavior.

Issue: SPR-14908

ServletContext.getMimeType() returns `null` for unknown mime types; not
`application/octet-stream`.

Issue: SPR-14908

This commit changes the `MediaTypeFactory` to return
`Optional<MediaType>` (instead of a plain `MediaType`) for the
`getMediaType` methods.

Issue: SPR-14908

CharSequenceEncoder now supports all MIME types, however since encoding
Flux<String> can overlap with other encoders (e.g. SSE) there are now
two ways to create a CharSequenceEncoder -- with support for text/plain
only or with support for any MIME type.

In WebFlux configuration we insert one CharSequenceEncoder for
text/plain (as we have so far) and a second instance with support for
any MIME type at the very end.

Issue: SPR-15374

Push the knowledge of what media types represent "streaming" down to
the Encoder level where knowledge is required (e.g. to encode a
JSON array vs a stream of JSON elements).

Changed the MethodNotAllowedException to use HttpMethod, instead of
Strings.

Issue: SPR-14925

This commit changes `ServerResponse` and subtypes to use properties
instead of fields during response rendering. This allows for overriding
these methods in a response subclass.

This commit introduces RenderingResponse.from(RenderingResponse),
allowing for easier response filtering.

This commit adds an integration test for the `RenderingResponse`.

This commit changes the `HandlerFilterFunction.ofResponseProcessor`
method signature to return `Mono<ServerResponse>`, to better cooperate
with response builders (which all return a `Mono`).

Issue: SPR-14925

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.