This change introduces a strategy for expanding a URI template into a
URI and makes it a property of the RestTemplate and AsyncRestTemplate
so that they can be pre-configured with such a strategy.

The DefaultUriTemplateHandler relies on UriComponentsBuilder internally
and provides functionality equivalent to using the UriTemplate.
A DefaultUriTemplateHandler can also be configured to parse the path
of a URI template into path segments in order to allow expanding URI
variables according to path segment encoding rules.

Issue: SPR-12750

Issue: SPR-12750

(cherry picked from commit a8f75399)

Issue: SPR-11694

Issue: SPR-12983

Before this change AbstractHandlerMethodMapping used a map from Method
to CorsConfiguration. That works for regular @RequestMapping methods.
However frameworks like Spring Boot and Spring Integration may
programmatically register the same Method under multiple mappings,
i.e. adapter/gateway type classes.

This change ensures that CorsConfiguraiton is indexed by HandlerMethod
so that we can store CorsConfiguration for different handler instances
even when the method is the same.

In order for to make this work, HandlerMethod now provides an
additional field called resolvedFromHandlerMethod that returns the
original HandlerMethod (with the String bean name). This makes it
possible to  perform reliable lookups.

Issue: SPR-11541

CorsConfiguration now provides methods to check and determine the
allowed origin, method, and headers according to its own configuration.

This simplifies significantly the work that needs to be done from
DefaultCorsProcessor. However an alternative CorsProcessor can still
access the raw CorsConfiguration and perform its own checks.

Issue: SPR-12885

This commit adds CORS related headers to HttpHeaders
and update DefaultCorsProcessor implementation to
use ServerHttpRequest and ServerHttpResponse instead
of HttpServletRequest and HttpServletResponse. Usage
of ServerHttpResponse allows to avoid using Servlet 3.0
specific methods in order keep CORS support Servlet 2.5
compliant.

Issue: SPR-12885

Issue: SPR-12960

Issue: SPR-12956

Issue: SPR-12296

Issue: SPR-12597

Issue: SPR-12925

Issue: SPR-12910

AbstractHttpMessageConverter now tries to call getDefaultContentType
with the actual value to be converted to see if that will result in
a more concrete mediat type than application/octet-stream.

Issue: SPR-12894

Issue: SPR-12854

Issue: SPR-10153

This commit introduces support for CORS in Spring Framework.

Cross-origin resource sharing (CORS) is a mechanism that allows
many resources (e.g. fonts, JavaScript, etc.) on a web page to
be requested from another domain outside the domain from which
the resource originated. It is defined by the CORS W3C
recommandation (http://www.w3.org/TR/cors/).

A new annotation @CrossOrigin allows to enable CORS support
on Controller type or method level. By default all origins
("*") are allowed.

@RestController
public class SampleController {

	@CrossOrigin
	@RequestMapping("/foo")
	public String foo() {
		// ...
	}
}

Various @CrossOrigin attributes allow to customize the CORS configuration.

@RestController
public class SampleController {

	@CrossOrigin(origin = { "http://site1.com", "http://site2.com" },
				 allowedHeaders = { "header1", "header2" },
				 exposedHeaders = { "header1", "header2" },
				 method = RequestMethod.DELETE,
				 maxAge = 123, allowCredentials = "true")
	@RequestMapping(value = "/foo", method = { RequestMethod.GET, RequestMethod.POST} )
	public String foo() {
		// ...
	}
}

A CorsConfigurationSource interface can be implemented by HTTP request
handlers that want to support CORS by providing a CorsConfiguration
that will be detected at AbstractHandlerMapping level. See for
example ResourceHttpRequestHandler that implements this interface.

Global CORS configuration should be supported through ControllerAdvice
(with type level @CrossOrigin annotated class or class implementing
CorsConfigurationSource), or with XML namespace and JavaConfig
configuration, but this is not implemented yet.

Issue: SPR-9278

Jackson 2.5.0 or later is required.

Issue: SPR-12501

This commit adds a filters property to MappingJacksonValue
and also manages a special FilterProvider class name model key in
order to be able to specify a customized FilterProvider for each
handler method execution, and thus provides a more dynamic
alternative to our existing JsonView support.

A filters property is also now available in Jackson2ObjectMapperBuilder
and Jackson2ObjectMapperFactoryBean in order to set easily a
global FilterProvider.

More details about @JsonFilter at
http://wiki.fasterxml.com/JacksonFeatureJsonFilter.

Issue: SPR-12586

Before this commit, Netty4ClientHttpRequest ignored query parameters
(?foo=bar). This commit fixes that.

Issue: SPR-12779

This commit introduces support for "Path Segment URI Variable
expansion", see https://tools.ietf.org/html/rfc6570#section-3.2.6.
In practice, this means that URI template variables prefixed with a '/'
are treated like path segments and - as such - will encode any '/'
found. For example: {/foo} expanded with "bar/baz" with result in
"bar%2F".

Issue: SPR-12750

AbstractContextLoaderInitializer and AbstractDispatcherServletInitializer support ApplicationContextInitializers now

Issue: SPR-12430

Issue: SPR-12865

(cherry picked from commit 673dac56)

This reverts commit a57d4282 after the
realization of a weaknesses with the proposed approach.

For example if a path segment contains both a /-prefixed and a regular
URI variable, there is no way to split that into a sequence of path
and path segments. The solution will have to be on the side of
UriComponents at the time of encoding.

Issue: SPR-12831

Prior to this commit, Cache-Control HTTP headers could be set using
a WebContentInterceptor and configured cache mappings.

This commit adds support for cache-related HTTP headers at the controller
method level, by returning a ResponseEntity instance:

ResponseEntity.status(HttpStatus.OK)
    .cacheControl(CacheControl.maxAge(1, TimeUnit.HOURS).cachePublic())
    .eTag("deadb33f8badf00d")
    .body(entity);

Also, this change now automatically checks the "ETag" and
"Last-Modified" headers in ResponseEntity, in order to respond HTTP
"304 - Not Modified" if necessary.

Issue: SPR-8550

This commit improves HTTP caching defaults and flexibility in
Spring MVC.

1) Better default caching headers

The `WebContentGenerator` abstract class has been updated with
better HTTP defaults for HTTP caching, in line with current
browsers and proxies implementation (wide support of HTTP1.1, etc);
depending on the `setCacheSeconds` value:

* sends "Cache-Control: max-age=xxx" for caching responses and
do not send a "must-revalidate" value by default.
* sends "Cache-Control: no-store" or "Cache-Control: no-cache"
in order to prevent caching

Other methods used to set specific header such as
`setUseExpiresHeader` or `setAlwaysMustRevalidate` are now deprecated
in favor of `setCacheControl` for better flexibility.
Using one of the deprecated methods re-enables previous HTTP caching
behavior.

This change is applied in many Handlers, since
`WebContentGenerator` is extended by `AbstractController`,
`WebContentInterceptor`, `ResourceHttpRequestHandler` and others.

2) New CacheControl builder class

This new class brings more flexibility and allows developers
to set custom HTTP caching headers.

Several strategies are provided:

* `CacheControl.maxAge(int)` for caching responses with a
"Cache-Control: max-age=xxx" header
* `CacheControl.noStore()` prevents responses from being cached
with a "Cache-Control: no-store" header
* `CacheControl.noCache()` forces caches to revalidate the cached
response before reusing it, with a "Cache-Control: no-store" header.

From that point, it is possible to chain method calls to craft a
custom CacheControl instance:

```
CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS)
    .cachePublic().noTransform();
```

3) Configuring HTTP caching in Resource Handlers

On top of the existing ways of configuring caching mechanisms,
it is now possible to use a custom `CacheControl` to serve
resources:

```
@Configuration
public class MyWebConfig extends WebMvcConfigurerAdapter {

  @Override
  public void addResourceHandlers(ResourceHandlerRegistry registry) {
    CacheControl cc = CacheControl.maxAge(1, TimeUnit.HOURS);
    registry.addResourceHandler("/resources/**)
            .addResourceLocations("classpath:/resources/")
            .setCacheControl(cc);
  }
}
```

or

```
<mvc:resources mapping="/resources/**" location="classpath:/resources/">
  <mvc:cachecontrol max-age="3600" cache-public="true"/>
</mvc:resources>
```

Issue: SPR-2779, SPR-6834, SPR-7129, SPR-9543, SPR-10464

This change improves the following use cases with
`WebRequest.checkNotModified(String etag)` and
`WebRequest.checkNotModified(long lastModifiedTimeStamp)`:

1) Allow weak comparisons for ETags

Per rfc7232 section-2.3, ETags can be strong or weak;
this change allows comparing weak forms `W/"etagvalue"` but does
not make a difference between strong and weak comparisons.

2) Allow multiple ETags in client requests

HTTP clients can send multiple ETags values in a single header such as:
`If-None-Match: "firstvalue", "secondvalue"`
This change makes sure each value is compared to the one provided by
the application side.

3) Extended support for ETag values

This change adds padding `"` to the ETag value provided by
the application, if not already done:
`etagvalue` => `"etagvalue"`

It also supports wildcard values `*` that can be sent by HTTP clients.

4) Sending validation headers for 304 responses

As defined in https://tools.ietf.org/html/rfc7232#section-4.1
`304 Not Modified` reponses must generate `Etag` and `Last-Modified`
HTTP headers, as they would have for a `200 OK` response.

5) Providing a new method to validate both Etag & Last-Modified

Also, this change adds a new method
`WebRequest.checkNotModified(String etag, long lastModifiedTimeStamp)`
in order to support validation of both `If-None-Match` and
`Last-Modified` headers sent by HTTP clients, if both values are
supported by the application code.

Even though this approach is recommended by the HTTP rfc (setting both
Etag and Last-Modified headers in the response), this requires more
application logic and may not apply to all resources produced by the
application.

Issue: SPR-11324

Issue: SPR-12750