Fix typo in method name.
Rename method to an accurate name ('close' is misleading)
HORNETQ-1128 Improve schema documentation, add some intra-manual links
Add description to assertion in test.
HORNETQ-1148 Bump the version to fail properly if server is older:
Connecting from a 2.3-client (now, version 123) to a 2.2 server will fail due
to serialization errors. Better a `version incompatibility` error.
Merge pull request #897 from FranciscoBorges/version-hq-1148

HORNETQ-1148 Bump the version to fail properly if server is older:
Merge pull request #896 from FranciscoBorges/schema

HORNETQ-1128 Improve schema documentation, add some intra-manual links
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).
changing tests