This commit adds support for HandlerFunctions and RouterFunctions to
DispatcherServlet, in the form of a HandlerAdapter and HandlerMapping.

See gh-21490

This commit represents a best effort attempt at fixing remaining
"a" vs. "an" grammatical errors related links specified via a fully
qualified class name.

Issue: SPR-17208

Issue: SPR-17083

This commit ignores errors like TransformerFactoryConfigurationError
that can be thrown when instantiating SourceHttpMessageConverter on
platforms where no TransformerFactory implementation is available,
like when compiling/running as GraalVM native images.

Issue: SPR-17007

Update all annotations so that each is on its own line and
consistently use the short form (i.e. don't use `value=`) when
possible.

Issue: SPR-16968

Fix checkstyle violations for javadoc.

Issue: SPR-16968

Issue: SPR-16336

Issue: SPR-16336

Issue: SPR-16743

Issue: SPR-16369

This commit adds support for configuring static resource locations
with a charset to be applied to relative paths.

https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Code-Style#line-wrapping

Prior to this commit, the Resource `HandlerMapping` configured by
`@EnableSpringMvc` would be set up with only one custom
`HandlerInterceptor` (the one exposing the `ResourceUrlProvider` for
resolving URLs of static resources).

This behavior is not consistent with the rest of the default
configuration which leverages the interceptors configured against the
interceptor registry (with possible user-provided ones).

This change allows to register interceptors against resource handling;
this can be useful for metrics purposes, as in
spring-projects/spring-boot#10335.

Issue: SPR-16034

Issue: SPR-16017

(cherry picked from commit 40ba95f8)

Prior to this commit, HTTP Range requests were only supported by the
ResourceHttpRequestHandler when serving static resources.

This commit improves the `HttpEntityMethodProcessor` and
the `RequestResponseBodyMethodProcessor`. They now extract
`ResourceRegion`s from the `Resource` instance returned by the
Controller and let the Resource-related message converters
handle the writing of the resource (including partial writes).

Controller methods can now handle Range requests for
return types that extend Resource or HttpEntity:

    @RequestMapping("/example/video.mp4")
    public Resource handler() { }

    @RequestMapping("/example/video.mp4")
    public HttpEntity<Resource> handler() { }

Issue: SPR-15789, SPR-13834

This commit ensure that null-safety is consistent between
getters and setters in order to be able to provide beans
with properties with a common type when type safety is
taken in account like with Kotlin.

It also add a few missing property level @Nullable
annotations.

Issue: SPR-15792

This commits extends nullability declarations to the field level, formalizing the interaction between methods and their underlying fields and therefore avoiding any nullability mismatch.

Issue: SPR-15720

Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.

Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.

Issue: SPR-15540

Issue: SPR-15540

This commit introduces 2 new @Nullable and @NonNullApi
annotations that leverage JSR 305 (dormant but available via
Findbugs jsr305 dependency and already used by libraries
like OkHttp) meta-annotations to specify explicitly
null-safety of Spring Framework parameters and return values.

In order to avoid adding too much annotations, the
default is set at package level with @NonNullApi and
@Nullable annotations are added when needed at parameter or
return value level. These annotations are intended to be used
on Spring Framework itself but also by other Spring projects.

@Nullable annotations have been introduced based on Javadoc
and search of patterns like "return null;". It is expected that
nullability of Spring Framework API will be polished with
complementary commits.

In practice, this will make the whole Spring Framework API
null-safe for Kotlin projects (when KT-10942 will be fixed)
since Kotlin will be able to leverage these annotations to
know if a parameter or a return value is nullable or not. But
this is also useful for Java developers as well since IntelliJ
IDEA, for example, also understands these annotations to
generate warnings when unsafe nullable usages are detected.

Issue: SPR-15540

Issue: SPR-15465

Issue: SPR-14923

This commit introduces a PathPatternParser which parses request pattern
strings into PathPattern objects which can then be used to fast
match incoming string paths. The parser and matching supports the syntax
as described in SPR-14544. The code is optimized around the common usages
of request patterns and is designed to create very little transient
garbage when matching.

Issue: SPR-14544

Issue: SPR-15109

This commit adds Smile and CBOR Jackson HttpMessageConverters
and make it possible to create Smile and CBOR ObjectMapper via
Jackson2ObjectMapperBuilder, which now allows to specify any
custom JsonFactory.

Like with JSON and XML Jackson support, the relevant
HttpMessageConverters are automaticially configurered by
Spring MVC WebMvcConfigurationSupport if jackson-dataformat-smile
or jackson-dataformat-cbor dependencies are found in the classpath.

Issue: SPR-14435

(cherry picked from commit 5222489a)

Issue: SPR-14599

Consistently use constructor-based instantiation instead of Class.newInstance / BeanUtils.instantiate

Issue: SPR-14486

Issue: SPR-13188

The MVC config now plugs the configured ContentNegotiationManager into
resource request handling.

Issue: SPR-13658