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"