BufferingStompDecoder message buffer size limit can now be configured
with JavaConfig MessageBrokerRegistry.setMessageBufferSizeLimit() or
with XML <websocket:message-brocker message-buffer-size="">.

Issue: SPR-11527

Before this change the StompDecoder decoded and returned only the first
Message in the ByteBuffer passed to it. So to obtain all messages from
the buffer, one had to loop passing the same buffer in until no more
complete STOMP frames could be decoded.

This chage modifies StompDecoder to return List<Message> after
exhaustively decoding all available STOMP frames from the input buffer.
Also an overloaded decode method allows passing in Map that will be
populated with any headers successfully parsed, which is useful for
"peeking" at the "content-length" header.

This change also adds a BufferingStompDecoder sub-class which buffers
any content left in the input buffer after parsing one or more STOMP
frames. This sub-class can also deal with fragmented messages,
re-assembling them and parsing as a whole message.

Issue: SPR-11527

Issue: SPR-11591

Revised ResizableByteArrayOutputStream as an actual subclass of ByteArrayOutputStream, and consistently applied appropriate ByteArrayOutputStream initial capacities across the codebase

Issue: SPR-11594

This commit adds new MockHttpServletRequestBuilder constructors
with an URI parameter in addition to the URL template + URL variables
existing ones.

It gives more control on how the URL is built, allowing for example to
use URL variables containing '/' character with proper encoding.

Issue: SPR-11441

Prior to this commit, the ShallowEtagHeaderFilter did not use the
content length given by the content generator to set the
ByteArrayOutputStream's buffer size.
This can lead to performance issues for large content since the buffer
grows as the content is being written.

This commit adds a new ByteArrayOutputStream variant called
ResizableByteArrayOutputStream. This implementation has public methods
for modifying the internal buffer size and does not synchronize on
buffer access.
This commit also make use of this new variant in
ShallowEtagHeaderFilter.

Issue: SPR-8271

Issue: SPR-11574

SessionFlashMapManager also clears the session attribute now when the given FlashMap List is empty.

Issue: SPR-11538

Issue: SPR-11548

Expand SockJS documentation

Issue: SPR-11437

Issue: SPR-11496, SPR-11525

Issue: SPR-11556

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

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

Since we now wrap the WebSocketSession with a concurrent decorator, the
synchronized keyword around message sending needed to be removed.

Issue: SPR-11586

- AnnotationAttributesReadingVisitor no longer processes annotations
  from the java.lang.annotation package.

- Simplified logic in AnnotationReadingVisitorUtils
  getMergedAnnotationAttributes().

Issue: SPR-11574

Issue: SPR-11581

Issue: SPR-11579

If a payload is present but conversion returns null (meaning no
converter knows how to convert), raise a MessageConversionException
that provides information about the type we were trying to convert
to and the message itself whose headers (namely content-type) contain
crucial information required to debug the problem.

Issue: SPR-11577

Prior to this commit, configuring a custom handshakeHandler when setting
up a stomp-endpoint with SockJS would not be taken into account:

  <websocket:stomp-endpoint path="/foo">
    <websocket:handshake-handler ref="customHandler"/>
    <websocket:sockjs/>
  </websocket:stomp-endpoint>

This commit fixes this by creating and registering a
WebsocketTransportHandler (with this handshakeHandler) as a
transportHandler override for the SockJSService.

Issue: SPR-11568

Issue: SPR-11586

When no @Payload is provided, it is equivalent to @Payload with default
attribute values. Since the default value of required=true, then
an argument that's not annotated is required.

A payload that is required will now throw an appropriate exception
regardless of if a conversion is required or not.

isEmptyPayload now takes the payload instead of the message
so that both the original payload and the converted payload, if
necessary, share the same logic.

JSR-303 validation is now consistently applied.

Issue: SPR-11577

Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.

In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.

The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.

The clientInboundChannel and clientOutboundChannel now use twice
the number of available processors by default to accomodate for some
degree of blocking in task execution on average.

In practice these settings still need to be configured explicitly in
applications but these should serve as better default values than
the default values in ThreadPoolTaskExecutor.

Issue: SPR-11450