HQ1104 STOMP 1.2 support

Implementation of STOMP version 1.2 support in HornetQ

Here is the STOMP V1.2 spec.
http://stomp.github.com/stomp-specification-1.2.html

STOMP v1.2 doesn't have much difference from v1.1. So it could be easily added to HornetQ based on the current code base with the following changes:

1. Refactor existing STOMP 1.0/1.1 code to improve code reusability.
2. Add the few new features mainly stated in the spec (see section 'Changes in the Protocol').
3. add an simple example
4. document update
5. tests

Below are details of general Stomp request processing

All incoming/outgoing bytes from/to a stomp client are processed by StompProtocolManager class. The StompProtocolManager creates a StompConnection for each client connection request.

Stomp version for each connection is determined during connection time, and so is the authentication.

Once connected, a StompConnection has a VersionedStompFrameHandler initiated. The VersionedStompFrameHandler has mainly two tasks:

task 1 : it uses a version specific decoder to decode stomp bytes into StompFrames
task 2 : it processes the decoded StompFrames and sends responses to client if needed.

Here is a summary of the VersionedStompFrameHandlers/decoders for each version

Stomp 1.0: StompFrameHandlerV10/StompDecoder
Stomp 1.1: StompFrameHandlerV11/StompDecoderV11
Stomp 1.2: StompFrameHandlerV12/StompDecoderV12

Here classes of higher versions usually inherits those of lower versions to maximize code reuse.

Message requests are converted into HornetQ core semantics and actually processed by the core layer.  Internally we have a StompSession to wrap a core session to do the work. It can be shown briefly using the following flow:

=(incoming bytes)==>StompProtocolManager==>StompConnection==>StompDecoder == (Stomp frames) ==> FrameHandler ==>StompSession ==> Core

Messages are sent to client in the following flow:

Core ==(core message)==>StompSession==>FrameHandler==(stomp frames)==>StompProtocolManager==>StompConnection===(physical network)==>client

Testing

We have a simple testing client to simulate STOMP clients. Related tests are in the following classes:

StompTest
ExtraStompTest
StompV11Test
StomeV12Test
Merge pull request #891 from gaohoward/br_STOMP12_HQ1104

HQ1104 STOMP 1.2 support
Fix a paging issue.

The issue could happen in the following case:

Say we have a live and a backup in replication mode. A client sends 20 messages (m0 to m19) to an address in two batches, each sending 10 messages. And the paging setup is such that it causes messages to be paged in the following detail:

1) first two (m0 and m1) are in the memory (not paged).
2) next 5 messages (m2 to m6) are paged into file 1.page.
3) next 3 messages (m7 to m9) are paged into file 2.page.
4) next 5 messages (m10 to m14) are paged into file 3.page.
5) next 5 messages (m15 to m19) are paged into file 4.page.

At backup server whose page files (1-4.page) are replicated to the backup's paging dir. Now if we let the following happen:

1) create a client to receive and commit first 10 messages.
2) crash live server immediately after.
3) the client receives the next 10 messages after failover.

After above step 1), 1.page and 2.page will be cleaned up. Accordingly the 1.page and 2.page at backup's paging store should be cleaned up too. However if step 2) comes too fast, the backup won't get a chance to receive the signal from live server to clean them up.

Now if 1.page and 2.page are left at backup and the backup starts failover, it will load the paging files (all 1, 2, 3, 4.page in order) and re-calculate a valid page file to set up proper paging store. Due to a miscalculation, only 1.page is dropped as used page but 2.page (whose messages are all consumed before failover) are taking as a valid page and loaded.

The result is that after failover the client will receive duplicated message (m7 to m9).
Fix typo in method name.
Rename method to an accurate name ('close' is misleading)
server-stop order
javadocs
server-stop: close sessions earlier