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

Issue: SPR-14233
(cherry picked from commit f83cbff5)

Before this commit the concurrent session wrapper mainly protected the
sending of messages. The close itself however may also cause a message
to be sent as is the case of the SockJS protocol.

This change protects the close and checks if the session has exceeded
send time or buffer limits in which case the close status is changed
to SESSION_NOT_RELIABLE (introduced in commit cbd5af3a) which in turn
signals that extra care should be exercised when closing the session.

Issue: SPR-13904

Issue: SPR-13761

Issue: SPR-13745

Issue: SPR-13548

Issue: SPR-13545

Issue: SPR-13464

Xnio 3.4.0 will introduce a new source of ByteBuffers: ByteBufferPool.
Previously this feature was offered by Pooled/Pool/ByteBufferSlicePool;
those classes are now marked as deprecated.

As of 1.3.0.Beta9, Undertow still implements the following method in its
ClientConnection interface, using those deprecated types:

    Pool<ByteBuffer> getBufferPool();

This commit prepares compatibility by suppressing warnings in order to
avoid build failures in our build. Once appropriate changes are made in
Undertow, a specific implementation with new types could be introduced.

Issue: SPR-13366

In an attempt to make our Jetty-based integration tests more robust,
this commit discontinues use of SocketUtils for picking a random,
available port and instead lets the Jetty Server pick its own port.

The StompSubProtcolHandler now checks the outcome of the send to the
inbound client channel. If the message was prevented from being sent,
e.g. as part of authorization, events are not published

Issue: SPR-13339

... with hope of reducing the fragility of these tests on the CI server.

Before this change, XhrTransport implementations had to be configured
with the headers to use for HTTP requests other than the initial
handshake.

After this change the handshake headers passed to SockJsClient by
default are used for all other HTTP requests related to the SockJS
connection (e.g. info request, xhr send/receive). A property on
SockJsClient allows restricting the headers to use for other HTTP
requests to a subset of the handshake headers.

Issue: SPR-13254

This commit replaces calls to System.out.println() with explicit logging.

Before this change <websocket:decorator-factory> decorated to
the SubProtocolWebSocketHandler RootBeanDefinition rather than
using a RuntimeBeanReference, which led to a separate instance
of SubProtocolWebSocketHandler to be created.

Issue: SPR-13190

Issue: SPR-12422

Recent builds of Jetty 9.3 require that Jetty's own ServletContext
implementation be supplied to WebSocketServerFactory's init() method.
Otherwise, the Jetty server will fail to start with the exception
message: "Not running on Jetty, WebSocket support unavailable".

This commit refactors AbstractWebSocketIntegrationTests,
AbstractSockJsIntegrationTests, and all WebSocketTestServer
implementations in order to support this new requirement.

Specifically:

- WebSocketTestServer defines a new getServletContext() method;
  TomcatWebSocketTestServer, UndertowTestServer, and
  JettyWebSocketTestServer have all been updated to return the
  ServletContext created by the embedded server.

- The setup() methods in AbstractWebSocketIntegrationTests and
  AbstractSockJsIntegrationTests have been updated so that the
  WebApplicationContext is supplied the appropriate ServletContext,
  after deployConfig() has been invoked on the WebSocketTestServer but
  before the WebApplicationContext is refreshed.

Issue: SPR-13162

The JettySockJsIntegrationTests are enabled in the performance build
only. Following the upgrade to Jetty 9.3 where the
JettyRequestUpgradeStrategy is now Lifecycle as wel as
ServletContextAware, we need to make sure the ApplicationContext
refresh occurs after the ServletContext has been set. This change
removes the explicit .refresh() call in the test setup and instead
relies on the DispatcherServlet to do that, which ensures that the
ServletContext with which it is initialized by Jetty has been set
on the ApplicationContext before that.

Issue: SPR-13140

Issue: SPR-13142

This change ensures that the deprecated UserSessionRegistry is still
used if configured.

Remove unused imports

Issue: SPR-12732

This change introduces SimpUserRegistry exposing an API to access
information about connected users, their sessions, and subscriptions
with STOMP/WebSocket messaging. Provides are methods to access users
as well as a method to find subscriptions given a Matcher strategy.

The DefaultSimpUserRegistry implementation is also a
SmartApplicationListener which listesn for ApplicationContext events
when users connect, disconnect, subscribe, and unsubscribe to
destinations.

The MultiServerUserRegistry implementation is a composite that
aggregates user information from the local SimpUserRegistry as well
as snapshots of user  on remote application servers.

UserRegistryMessageHandler is used with MultiServerUserRegistry. It
broadcats user registry information through the broker and listens
for similar broadcasts from other servers. This must be enabled
explicitly when configuring the STOMP broker relay.

The existing UserSessionRegistry which was primiarly used internally
to resolve a user name to session id's has been deprecated and is no
longer used. If an application configures a custom UserSessionRegistr
still, it will be adapted accordingly to SimpUserRegistry but the
effect is rather limited (comparable to pre-existing functionality)
and will not work in multi-server scenarios.

Issue: SPR-12029

Since SPR-10954, the SimpleBrokerMessageHandler supports `heart-beats`.

Even if the STOMP spec states that the `heart-beat` header is OPTIONAL,
and if absent considered as `heart-beat: 0,0`,
some clients rely on this to be set in CONNECTED frames.

This commit adds this header information even if no task
scheduler/heart-beat have been configured.

See: https://stomp.github.io/stomp-specification-1.2.html#Heart-beating

Issue: SPR-10954

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-12956

Issue: SPR-12955

This change adds support for broadcasting messages with unresolved
user destinations so that other servers can try to resolve it.
That enables sending messages to users who may be connected to a
different server.

Issue: SPR-11620

Issue: SPR-10954

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