Issue: SPR-14527

Switch from returning Mono<WebSocketSession> to take a WebSocketHandler
and return Mono<Void> for the entire session handling.

The WebSocketHandler callback delimits the stard and end of protocol
handling and forces the handler to operate within the scope of the
Reactor operators.

Give the full duplex nature of WebSockets, the symmetry between client
and server (each now using WebSocketHandler) also seems appropriate.

Issue: SPR-14527

Issue: SPR-15031

HandshakeInfo has been promoted to the top-level socket package next to
WebSocketSession which exposes it.

Issue: SPR-14832

Issue: SPR-15028

Issue: SPR-14527

The WebSocketHander adapters are now neutral for client vs server-side
use with the adapters for RxNetty and Reactor Netty (server-side only)
completely removed.

A new HandshakeInfo carries information about the handshake including
URI, headers, and principal from the upgrade strategy, to the adapter,
and then to the session.

WebSocketSession exposes the HandshakeInfo as well reducing its overall
number of methods.

Move WebSocketMessage factory methods to the WebSocketSession which
has the bufferFactory() needed to create message payloads.

WebSocketMessage is left with one public constructor.

WebSocketMessage exposes convenience retain/releasePayload methods.

Expose bufferFactory() at the WebSocketSession level for creating
payloads like ReactiveHttpOutputMessage does.

Promote getId(), getUri(), and bufferFactory() to the base class
WebSocketSessionSupport.

Includes consistent use of ResolvableType.resolve() wherever applicable.

Issue: SPR-15011

Issue: SPR-14978

Apply the new HttpHeaders#getAcceptLanguageAsLocale() in places where
it was hardcoded or defaulting.

Apply ServerHttpResponse.encodeUrl in RequestContext.

Issue: SPR-15024

An update on the last commit switching from:
List<Locale> getAcceptLanguageAsLocales() to
Locale getAcceptLanguageAsLocale()

This best supports the scenario for the most preferred Locale.
If there is a need to look at the prioritized list of languages it's
best to use Locale.filter with the LocaleRange's.

This is explained in the Javadoc for getAcceptLanguage().

Issue: SPR-15024

The use of Locale.LanguageRange for the Accept-Language header makes
sense as it gives the most flexibility for a client to set a weighted
list and for a server to do filtering via Locale#filter.

This commit adds an additional convenience method that turns
the LangugeRange list to a list of Locale's also filtering out a
wildcard (i.e. "*"). A List<Locale> is the most basic way to access
prefered languages and needed when filtering is not required.

Issue: SPR-15024

Consolidate into one method potentially re-using UriComponentsBuilder
for the location. Also use StringUtils#applyRelativePath.

Issue: SPR-15020

Previously ForwrdedHeaderFilter did not ensure that
HttpServletResponse.sendRedirect worked properly based on
X-Forwarded-* headers.

This commit updates ForwardedHeaderFilter to overrided the
HttpServletResponse.sendRedirect method to ensure
X-Forwarded-* headers are honored.

Issue SPR-15020

ServerWebExchange.Builder has an additional Consumer-style shortcut
method that accepts a builder for modifying the request.

ServerWebExchange and ServerHttpRequest builders have fewer methods,
more use-case focused vs matching directly to properties.

ServerWebExchange now provides access to "requestParams" as a
MulitValueMap with query parameters and form data combined.

The combined map is then used for the params condition of
@RequestMapping purposes () and also for @RequestParam arguments.

Issue: SPR-15000

Issue: SPR-14536

Issue: SPR-15024

Issue: SPR-14978

Issue: SPR-15017

Issue: SPR-14992

Renamed:
AbstractListenerFlushProcessor -> AbstractListenerWriteFlushProcessor