BUG 2509 : Removing all journal entries from a Followers in-memory journal causes Leader to send an InstallSnapshot

This patch simply checks if an AppendEntries#prevLogIndex is equal to the followers ReplicatedLog#snapshotIndex. If
both are the same it also verifies that the AppendEntries#prevLogTerm is equal to the followers ReplicatedLog#snapshotTerm.
This is sufficient in most cases to prevent a re-installation of a snapshot when the AppendEntries message is supposed
to immediately follow the snapshot.

Change-Id: Iab9b493455538544efd06334329f91cc426d61f8
Signed-off-by: Moiz Raja <moraja@cisco.com>
BUG 2464 : Shard dataSize does not seem to correspond to actual memory usage

The dataSize that is reported is the "serialized" size of the payload. Since the replicated
log actually contains the CompositeModification object (which may hold on to a lot more memory)
the serialized size is not neccessarily the same as the object size.

To make the data size correspond to memory usage and to actually reduce memory usage this patch
creates a new payload class called CompositeModificationByteStringPayload which only stores the
ByteString which is an order of magnitude smaller. Custom serialization ensures that this object
is written and read correctly.

This patch is backward compatible in that a replicated log containing a CompositeModificationPayload
will be read correctly but is not forward compatible in that if a new controller instance were to send
a CompositeModificationPayload to an older instance it would not work.

To ensure that we do not need to immediately require a conversion from ByteString to PersistentMessages.CompositeModification we maintain a SoftReference to CompositeModification.

Change-Id: I32c921dea2d39ed689aa2fb6f68eb8528be920d0
Signed-off-by: Moiz Raja <moraja@cisco.com>
Merge "BUG 2464 : Shard dataSize does not seem to correspond to actual memory usage"
Merge "BUG 2509 : Removing all journal entries from a Followers in-memory journal causes Leader to send an InstallSnapshot"