Bug 2948: Recovered log entries not applied after prior snapshot

Bug 2948: Recovered log entries not applied after prior snapshot

Modified SnapshotManager#capture to obtain and cache the last journal sequence
number. On commit, the cached sequence number is used to delete
messages. This preserves any ApplyJournalEntries and ReplicatedLogEntry
messages that occur after the capture is initiated.

As a result of his change, we also have to obtain the unapplied entries
at the time the snapahot is initiated and not when we persist.
Otherwise, log entries persisted after the capture is initiated and
before it's persisted would be included in the snapshot's unapplied
list. On recovery, both entries would be recovered and added to the in-memory
journal resulting in duplicate entries.

These changes may result in a subsequent modification that is applied
after the snapshot is initiated to be included in the snapshot and also
persisted in the journal or included as unapplied in the snapshot. On
recovery, the modification entry would be redundantly applied. This could
result in data tree errors, eg if the modification was a delete, the
redundant apply would cause an exception due to the non-existent node.
We'll have to live with that - I think the only way to prevent it is if
we create the snapshot synchronously. Note this could also have occurred
before these changes.

Change-Id: I745d94f5417e17627c1c4d53be8d6fdf01587d35
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>