Improve handling of send failures

Prior to this commit, a failure to send a heartbeat was ignored and a
failure to forward a message to the broker would result in an error
frame being sent but nothing more.

Following this commit, a failure to send a heartbeat to the broker
is treated as a TCP client failure. Furthermore, if the system relay
session fails to forward a message to the broker an exception is
thrown. Typically, the system relay session will be forwarding
messages on behalf of local application code, rather than a remote
WebSocket client. Throwing an exception allows the application code
to be notified of the problem directly, rather than via a broker
availability event.
Introduce CONNECT_ACK message type

Previously, handling of a STOMP CONNECT message and sending of a
CONNECTED response was performed by StompProtocolHandler if it was
backed by SimpleBrokerMessageHandler, or left up to the real message
broker if it was backed by StompBrokerRelayMessageHandler. This
wasn't ideal as it should be StompProtocolHandler's job to simply map
messages to and from the STOMP protocol, not to do part of the
broker's job and respond directly to CONNECT.

This commit introduces a new message type, CONNECT_ACK. When it
receives a CONNECT message, SimpleBrokerMessageHandler will now
respond with a CONNECT_ACK message that StompProtocolHandler can map
into a STOMP CONNECTED message. The CONNECT_ACK message contains the
CONNECT message as a header so that StompProtocolHandler has access to
its accept-version header.

StompProtocolHandler has been simplified so that a CONNECT message
is always passed to the output channel, irrespective of whether it's
backed by a simple broker or a real broker. The handleConnect flag,
and the code that would set it correctly depending on the app's
configuration, has been removed.
Polishing

 - Polish javadoc for CONNECTED_USER_HEADER
 - Improve method ordering
Polish and fix issues in STOMP broker relay

Fix error in te code that handles the result of sending a heartbeat

Fix error in processing DISCONNECTED frames that closed the TCP
connection before the message was sent.
Fix issue in simple broker with peer-to-peer messages

Issue: SPR-10930
Fix issue with getting SockJS path

Issue: SPR-10923
Prevent cache of sockjs known prefixes from growing

Issue: SPR-10893
Update Spring MVC Java config for ResourceResolvers
Fix failing test
Improve broker relay's shutdown and availability events

Previously, when the broker relay was shut down, the TCP client was
closed and the relay sessions were left to find out about the
shutdown as a result of their TCP connections being closed. This led
to problems where an attempt could be made to use a session that was,
in fact, in the process of being shut down.

This commit updates the broker relay to explicitly close each of its
relay sessions as part of its stop processing.
As part of the broker relay being shut down explicitly close each of
its relay sessions. It does so before closing the TCP client so that
the relay sessions know that they are  disconnected before their TCP
connections are closed.

The broker relay's publishing of availability events has also been
improved. Prior to this commit, availability events were published
based on the availability of any relay session. For example, this
meant that a successfully established client relay session would
result in an event being published indicating that the broker's
available even if the system relay session was yet to be established.
This commit updates the relay so that broker availability events are
only published by the system relay session. This allows application
code the use these events as an accurate indication of the
availability of the broker. Clients that are interested in the
broker's availability can find out through the use of heart beats or
through the receipt of an ERROR frame in response to an attempt to
communnicate with the broker.
Make the broker relay heartbeat intervals configurable

Prior to this commit, the intervals at which the broker relay's system
session would send heartbeats to the STOMP broker and expect to
receive heartbeats from the STOMP broker were hard-coded at 10
seconds.

This commit makes the intervals configurable, with 10 seconds being
the default value.
Introduce new HEARTBEAT message type

Previously, there was no generic concept of a message that represents
a heartbeat and the STOMP-specific code used a null STOMP command to
represent a heartbeat.

This commit introduces HEARTBEAT as a new SimpMessageType. The STOMP
support has been updated to create HEARTBEAT messages to represent
heartbeats, and to use the new message type as the mechanism by which
heartbeats are identified.
Add javax.servlet.http.Part support for data binding

Prior to this commit, Multipart databinding would only support
MultiPartFile databinding using commons-multipart.

Now the WebRequestDataBinder supports Part and List<Part>
databinding for Servlet 3.0 compliant containers.

Issue: SPR-10591
Add Jackson's Modules registration in Jackson2OMFactoryBean

Prior to this commit, one couldn't configure Jackson's ObjectMapper
with (De)SerializerModifiers or advanced configuration features
using XML configuration.

This commit updates the FactoryBean and adds a setModule method
that will register Modules with the ObjectMapper.

Note that this commit is only about XML configuration, since
this feature was already available with JavaConfig.

Issue: SPR-10429
Make method in RequestMappingHandlerMapping protected

Issue: SPR-10950
Polishing
Introduced TomcatLoadTimeWeaver for Tomcat's new InstrumentableClassLoader interface

At the same time, dropped GlassFish 1/2 support from GlassFishLoadTimeWeaver and redesigned it to be as analogous to TomcatLoadTimeWeaver as possible.

Issue: SPR-10788
Turned ByteBufferConverter's visibility to package level
Marked Jackson 1.x support classes as deprecated
Polishing