Issue: SPR-13745

Issue: SPR-13753
(cherry picked from commit 747863d5)

Issue: SPR-13326

Prior to this change, duplicate SubProtocolHandlers could be registered
when configuring STOMP with several registrations:

    public void registerStompEndpoints
          (final StompEndpointRegistry registry) {
      this.endpointRegistry.addEndpoint("/stompOverWebSocket");
      this.endpointRegistry.addEndpoint("/stompOverSockJS").withSockJS();
    }

This commit registers sub-protocols in a Set instead of a list (see
SubProtocolWebSocketHandler), thus fixing the issue.

Issue: SPR-12403

Issue: SPR-12247

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

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 adds collection of stats in key infrastructure components
of the WebSocket message broker config setup and exposes the gathered
information for logging and viewing (e.g. via JMX).

WebSocketMessageBrokerStats is a single class that assembles all
gathered information and by default logs it once every 15 minutes.
Application can also easily expose to JMX through an MBeanExporter.

A new section in the reference documentation provides a summary of
the available information.

Issue: SPR-11739

Issue: SPR-11884

When a WebSocket session is closed after not having received any
messages, we'll use SESSION_NOT_RELIABLE to indicate to other parts
of the session closing code not to send anything further (e.g.
SockJS "Go Away!" frame).

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

Sessions connected to a STOMP endpoint are expected to receive some
client messages. Having received none after successfully connecting
could be an indication of proxy or network issue. This change adds
periodic checks to see if we have not received any messages on a
session which is an indication the session isn't going anywhere
most likely due to a proxy issue (or unreliable network) and close
those sessions.

Issue: SPR-11884

This change ensures that StompSubProtocolHandler is injected with an
ApplicationEventPublisher for both the Java and XML config.

Issue: SPR-11825

spring-websocket is full of unused imports. This commit removes all
unused imports from spring-websocket.

Proactively notify all active WebSocket sessions when a shutdown is
progress. Sessions then can ignore further attempts to send messages
and also stop stop trying to flush messages right away.

Issue: SPR-11578

Issue: SPR-11527

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 the decorator ensured that for a specific WebSocket
session only one thread at a time can send a message. Other threads
attempting to send would have their messages buffered and each time
that occurs, a check is also made to see if the buffer limit has been
reached or the send time limit has been exceeded and if so the session
is closed.

This change adds further protection to ensure only one thread at a time
can perform the session limit checks and attempt to close the session.
Furthermore if the session has timed out and become unresponsive,
attempts to close it may block yet another thread. Taking this into
consideration this change also ensures that state associated with the
session is cleaned first before an attempt is made to close the session.

Issue: SPR-11450

Issue: SPR-11586

Issue: SPR-11531

Consistent ".jetty" and ".standard" subpackages; consolidated GlassFishRequestUpgradeStrategy implementation; renamed Text/BinaryWebSocketHandler and moved them to web.socket.support

This commit adds an XML namespace equivalent of @EnableWebSocket and
@EnableWebSocketMessageBroker. Those are <websocket:handlers> and
<websocket:message-broker> respectively.

Examples can be found in the test suite.

This commit also alters the way MessageHandler's subscribe to their
respective MessageChannel's of interest. Rather than performing the
subscriptions in configuration code, the message channels are now
passed into MessageHandler's so they can subscribe themselves on
startup.

Issue: SPR-11063

Apply consistent styling to new classes introduced in Spring 4.0.

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

The addition of SubProtocolCapable simplifies configuration since it is
no longer necessary to explicitly configure DefaultHandshakeHandler
with a list of supported sub-protocols. We will not also check if the
WebSocketHandler to use for the WebSocket request is an instance of
SubProtocolCapable and obtain the list of sub-protocols that way. The
provided SubProtocolWebSocketHandler does implement this interface.

Issue: SPR-11111

Before this change spring-messaging contained a few WebSocket-related
classes including WebSocket sub-protocol support for STOMP as well
as @EnableWebSocketMessageBroker and related configuration classes.

After this change those classes are located in the spring-websocket
module under org.springframework.web.socket.messaging.

This means the following classes in application configuration must
have their packages updated:

org.springframework.web.socket.messaging.config.EnableWebSocketMessageBroker
org.springframework.web.socket.messaging.config.StompEndpointRegistry
org.springframework.web.socket.messaging.config.WebSocketMessageBrokerConfigurer

MessageBrokerConfigurer has been renamed to MessageBrokerRegistry and
is also located in the above package.

Issue: SPR-10835

Issue: SPR-10835

Update methods available on WebSocketSession interface.
Introduce DelegatingWebSocketSession interface.

Add SubProtocolHandler to encapsulate the logic for using a
sub-protocol.

A SubProtocolWebSocketHandler is also provided to
delegate to the appropriate SubProtocolHandler based on the
negotiated sub-protocol value at handshake.

StompSubProtocolHandler provides handling for STOMP messages.

Issue: SPR-10786