First close all sessions, THEN start waiting for completion.
Remove the setContext call, from server.stop() as the methods inside
ServerSession are already handling the context switching.

Also make the sessionContext 'final', it simplifies the code and we
can assume more about it
Merge pull request #898 from FranciscoBorges/stop-server-sessions

First close all sessions, THEN start waiting for completion.
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