Before this change SockJsSession implementations of WebSocketSession
used synchronization around its method implementations protecting
internal state and ensuring only a single thread is sending messages
at a time.

A WebSocketSession is generally expected to be used from one thread
at a time and now that application messages are sent through
ConcurrentWebSocketSessionDecorator, there is no concern about
application messages sent from the different threads.

While there are some remaining concerns, those can be addressed
without using the synchronized keyword. This change removes it from
the methods of all SockJS session implementations.

Issue: SPR-11450

Issue: SPR-11566

sockjs-client expects a prelude to be written on every request with
streaming transports. The protocol tests don't make this clear and
don't expose this issue.

The test case for SPR-11183 (writing 20K messages in succession) did
expose the issue and this commit addresses it.

Issue: SPR-11183

Introduced SockJsSession interface and moved SockJsSessionFactory and SockJsServiceConfig to sockjs.transport; added initialize(SockJsServiceConfig) method to TransportHandler interface; extracted TransportHandlingSockJsService from DefaultSockJsService; moved sockjs.support.frame to sockjs.frame and extracted (Default)SockJsFrameFormat from SockJsFrame; moved SockJsHttpRequestHandler to sockjs.support; removed Jackson 1.x support

Apply consistent styling to new classes introduced in Spring 4.0.

- Javadoc line wrapping, whitespace and formatting
- General code whitespace
- Consistent Assert.notNull messages

- Removed unused imports
- Organized imports
- Deleted unused fields
- Deleted unused local variables
- Deleted unused private static classes

- add WebSocketHttpHeaders
- client-side support for WebSocket extensions
- DefaultHandshakeHandler updates
- replace use of ServletAttributes in JettyRequestUpgradeStratey
- upgrade spring-web to jetty 9.0.5

This commits adds simple, overridable WebSocket Extension
filtering during the handshake phase and adds that
information in the WebSocket session.

The actual WebSocket Extension negotiation happens
within the server implementation (Glassfish, Jetty, Tomcat...),
so one can only remove requested extensions from
the list provided by the WebSocket client.

See RFC6455 Section 9.

Issue: SPR-10843

Issue: SPR-10854

Issue: SPR-10844

A HandshakeInterceptor can be used to intercept WebSocket handshakes
(or SockJS requests where a new session is created) in order to
inspect the request and response before and after the handshake
including the ability to pass attributes to the WebSocketHandler,
which the hander can access through
WebSocketSession.getHandshakeAttributes()

An HttpSessionHandshakeInterceptor is available that can copy
attributes from the HTTP session to make them available to the
WebSocket session.

Issue: SPR-10624

Update methods available on WebSocketSession interface.
Introduce DelegatingWebSocketSession interface.

Add a factory method in ServerHttpRequest for creating a
ServerHttpAsyncRequestControl.

See javadoc in SockJsService for details.

Also remove ReadOnlyMultiValueMap, CollectionUtils has a method for
that already.

ServerHttpAsyncResponseControl wraps a ServetHttpRequest and -Response
pair and allows putting the processing of the request in async mode
so that the response remains open until explicitly closed, either from
the current or from another thread.

ServletServerHttpAsyncResponseControl provides a Serlvet-based
implementation.

After this change the top-level sockjs package contains the main types
for use in applications.

It makes it possible to deploy multiple WebSocketHandler's to a URL,
each supporting a different sub-protocol.

Issue: SPR-10786

Minor polish to formatting and assertion messages.

Issue: SPR-10130

org.springframework.websocket  -> org.springframework.web.socket
org.springframework.sockjs     -> org.springframework.web.socket.sockjs

Flatten .sockjs and .sockjs.server

Allow WebSocketHandler methods to raise an exception.

By default we install ExceptionWebSocketHandlerDecorator, which logs
unhandled exceptions and closes the session. That decorator can be
extended or replaced.

Any exceptions that remain unhandled still (i.e. no exception handling
decorator), are caught in the lowest level before propagating to the
WebSocket engine or a SockJS transport handler and handled the same
way. That means default behavior is guaranteed but also fully
customizable.

WebSocketHandler implementations:
- methods must deal with exceptions locally
- uncaught runtime exceptions are handled by ending the session
- transport errors (websocket engine) are passed into handleError

WebSocketSession methods may raise IOException

SockJS implementation of WebSocketHandler:
- delegate SockJS transport errors into handleError
- stop runtime exceptions from user WebSocketHandler and end session

SockJsServce and TransportHandlers:
- raise IOException or TransportErrorException

HandshakeHandler:
- raise IOException

HandlerProvider is now an interface that can be used to plug in
WebSocket handlers with per-connection scope semantics. There are two
implementations, of the interface, one simple and a second that creates
handler instances through AutowireCapableBeanFactory.

HandlerProvider also provides a destroy method that is used to
apply a destroy callback whenever a client connection closes.

There is now a WebSocketMessage type with TextMessage and BinaryMessage
sub-types. WebSocketHandler is also sub-divided into TextMessageHandler
and BinaryMessageHandler, so that applications can choose to handle
text, binary, or both.

Also in this commit, the SockJsHandler and SockJsSession interfaces
have been removed. SockJsService now accepts WebSocketHandler.

As opposed to close(), which actively closes the session, the
onClosed method is called when the underlying connection has been
closed or disconnected.

Add HandlerProvider<T> class
Modify HandshakeHandler to accept + adapt WebSocketHandler at runtime
Modify SockJsService to accept + adapt SockJsHandler at runtime

This is useful to make sure response headers are written to the
underlying response. It is also useful in conjunction with long
running, async requests and HTTP streaming, to ensure the Servlet
response buffer is sent to the client without additional delay and
also causes an IOException to be raised if the client has gone away.

- configure SockJS handler by type (as well as by instance)
- add method to obtain SockJS handler instance via SockJsConfiguration
- detect presense of jsr-356 and use it if available