Issue: SPR-13192

Issue: SPR-13191

Browsers like Chrome or Safari include an Origin header for same-origin
POST/PUT/DELETE requests, not only for cross-origin requests.

Before this commit, these same-origin requests would have been detected
as potential cross-origin requests, and rejected if the same-origin domain
is not part of the configured allowedOrigins.

This commit avoid to reject same-origin requests by reusing the logic
introduced in Spring 4.1 for detecting reliably Websocket/SockJS
same-origin requests with the WebUtils.isValidOrigin() method. This
logic has been extracted in a new WebUtils.isSameOrigin() method.

Issue: SPR-13206

This commit introduces the following changes:
 - The new CorsConfigurationMapping class allows to share the mapped
   CorsConfiguration logic between AbstractHandlerMapping and CorsFilter
 - In AbstractHandlerMapping, the Map<String, CorsConfiguration>
   corsConfiguration property has been renamed to corsConfigurations
 - CorsFilter allows to process CORS requests at filter level, using any
   CorsConfigurationSource implementation (for example
   CorsConfigurationMapping)

Issue: SPR-13192

Issue: SPR-13193

When using Appache Commons FileUpload, multi parts with binary data
(i.e. that are not actual files) are saved and then accessed as
String request parameters.

Before this change however the RequestPartServletServerHttpRequest
used a fixed encoding (UTF-8) while the parsing code in
CommonsFileUploadSupport/Resolver used the encoding from the
content-type header, or the request, or the FileUpload component.

This change does a best effort to determine the encoding of the
request parameter using a similar algorithm as the parsing side
that should work the same unless the encoding comes from the
FileUpload component which is not accessible.

Issue: SPR-13096

Issue: SPR-13200

Issue: SPR-11861

Issue: SPR-13194

Issue: SPR-13004

This split avoids a package tangle (between core and core.annotation) and also allows for selective use of raw annotation exposure versus synthesized annotations, with the latter primarily applicable to web and message handler processing at this point.

Issue: SPR-13153

Prior to this commit, `HttpEntityMethodProcessor` would rely on
`ServletWebRequest` to process conditional requests and with incoming
`"If-Modified-Since"` / `"If-None-Match"` request headers.

This approach is problematic since in that class:

* response is wrapped in a `ServletServerHttpResponse`
* this wrapped response does not write response headers right away
* `ServletWebRequest.checkNotModified` methods can't apply their
logic with incomplete response headers

This solution adds some minimal code duplication and applies
the conditional request logic within the Processor.

A possible alternative would be to improve the
`ServletServerHttpResponse$ServletResponseHttpHeaders` implementation
with write methods - but this solution would only work for Servlet 3.x
applications.

Issue: SPR-13090

- Simplified "check" algorithms in CorsConfiguration

- Improved robustness of setter methods in CorsConfiguration in order to
  avoid attempts to modify immutable lists

- Improved CORS documentation and fixed typo

- Introduced constants in CorsConfiguration

- Removed auto-boxing in CorsRegistration

Issue: SPR-11193

Before this change HandlerMethodReturnValueHandler's were invoked in a
specific order (type-based, annotation-based, custom). However handlers
that deal with asynchronous return value handling need to always be
considered first. This affects custom handlers in particular since they
are normally ordered last.

This change introduces an AsyncHandlerMethodReturnValueHandler
sub-interface with a single method to determine if the return value is
asynchronous and if it is to look for a matching handler only among
those that are of type AsyncHandlerMethodReturnValueHandler.

Issue: SPR-13083

Before this change a missing path variable value resulted in a 400
error where in fact the error is due to a mismatch between the
declared @PathVariable and the URI template, i.e. a 500 error.

This change introduced a MissingPathVariableException as a sub-class
of ServletRequestBindingException (the exception previously thrown)
and results in a response status code of 500 by default.

Issue: SPR-13121

- origin --> origins
- method --> methods
- constants are now actually constant (i.e., static final)

Prior to this change, the `"Last-Modified"` and "`Etag`" support had
been improved with SPR-11324: HTTP response headers are now
automatically added for conditional requests and more.

This commit fixes the format of the "`Last-Modified`" and "`ETag`"
values, which were using an epoch timestamp rather than an HTTP-date
format defined in RFC 7231 section 7.1.1.1.

Also, Conditional responses are only applied when the given response
applies, i.e. when it has an compatible HTTP status (2xx).

Issue: SPR-13090

Issue: SPR-13112

Issue: SPR-13104

This commit introduces support for RFC 7239: Forwarded HTTP Extension in
the UriComponentsBuilder. Unfortunately, RFC 7239 is not a complete
replacement for the X-Forwarded-* headers: specifically, there is not
direct replacement for X-Forwarded-Port. The JIRA contains more
information.

Issue: SPR-11856

Issue: SPR-13097

Issue: SPR-11393

Issue: SPR-11393

Issue: SPR-11393

Issue: SPR-11393