Even before this change SockJS sessions always cancelled the heartbeat
task first prior to sending messages. However when the heartbeat task
is already in progress, cancellation of it is not enough and we must
wait until the heartbeat is sent.

This commit adds a heartbeat write lock which is obtained and held
during the sending of a heartbeat. Now when sessions send a message
they still cancel the heartbeat task but if that fails they also wait
for the heartbeat write lock.

Issue: SPR-14356

After this change the StompSubProtocolHandler sends STOMP frames
with content-type=octet-stream as a binary WebSocket message.

Issue: SPR-12475

Issue: SPR-12311

WebSocket clients going away is an expected and common occurance.
Logging at ERROR level on failure to close a connection or on failures
to write data to a WebSocket sessions has a high potential for false
positives with very little to do. This change lowers the log level for
a number of log messages that fit this category.

This should be helped by the effort already spent for 4.1 to ensure
logging at DEBUG level doesn't produce excessive amounts of logging.

Issue: SPR-12155

Issue: SPR-11870

This change removes most logging at INFO level and also ensures the
amount of information logged at DEBUG level is useful, brief, and
not duplicated.

Also added is custom logging for STOMP frames to ensure very readable
and consise output.

Issue: SPR-11934

This change ensures the state of a SockJS session is set to CLOSED
immediately after close is invoked. This avoids duplicate invocations
of afterConnectionClosed in WebSocket transport.

Issue: SPR-11884

Update WebSocketSession toString methods to include the handshake URI
and add id and URI fields to ensure they're available after close().

Log WebSocket session open and close events at INFO.

Remove trace messages for destinations that do not match.

Issue: SPR-11884

Optimize logging with tracking the opening and closing of WebSocket
sessions and STOMP broker connections in mind.

While the volume of messages makes it impractical to log every message
at anything higher than TRACE, the opening and closing of connections
is more manageable and can be logged at INFO. This makes it possible to
drop to INFO in production and get useful information without getting
too much in a short period of time.

The logging is also optimized to avoid providing the same information
from multiple places since messages pass through multiple layers.

Issue: SPR-11884

This change ensures the server "WebSocketHandler" is notified of the
opening of a session before writing the open frame to the remote
handler. Any messages sent by the server "WebSocketHandler" while
getting notified of the opening get cached and flushed after the open
frame has been written.

This change introduces locking in AbtractHttpSockJsSession to guard
access to the HTTP response. The goal is to prevent contention between
client requests to receive messages (i.e. long polling) and
the application trying to write.

Issue: SPR-11916

When a send timeout is detected, the WebSocket session is now closed
with a custom close status that indicates so. This allows skipping
parts of the close logic that may cause further hanging.

Issue: SPR-11450

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

This change exposes the WebSocketSession attributes through a message header.
The StompSubProtocolHandler adds this to incoming messages.
For now messaging handling  methods can access the map via @Header, e.g.:

@Header(StompHeaderAccessor.SESSION_ATTRIBUTES) Map<String, Object> attrs) {

Issue: SPR-11566

Issue: SPR-11566

The Servlet API does not provide notifications when a client
disconnects, see see https://java.net/jira/browse/SERVLET_SPEC-44.
Therefore network IO failures may occur simply because a client has
gone away. Before this change that could fill logs with unnecessary
stack traces.

After this change we make a best effort to identify such network
failures, on a per-server basis (tested with Jetty, Tomcat, Glassfish,
and WildFly), and log them under a separate log category.

A simple one-line message is logged at DEBUG level (i.e. no stack trace)
while a full stack trace is shown at TRACE level.

Issue: SPR-11438

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

Issue: SPR-11201

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

Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.

Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.

Issue: SPR-11064

Issue: SPR-10703

After this change the DefaultHandshakeHandler delegates to a
server-specific RequestUpgradeStrategy to update the HTTP response for
the handshake request and to begin the WebSocket interaction.

The DefaultHandshakeHandler however still retains the initial
validation of the WebSocket handshake including negotation of origin,
sub-protocol, etc. This allows sub-classes to override various
aspects of the negotiation independant of the WebSocket engine.

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.

See javadoc in SockJsService for details.

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

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

A SockJS message frame is an array of JSON-encoded messages and before
this change the use of the Jackson 2 library was hard-coded.

A Jackson 2 and Jackson 1.x implementations are provided and
automatically used if those libraries are present on the classpath.

Issue: SPR-10800

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