BUG 2371 : Leader should reset it's snapshot tracking when follower is restarted

This patch adds a new protocol to InstallSnapshot. It the InstallSnapshotReply returns
a failure and the chunkIndex is -1 then the Leader will reset the FollowerSnapshot so
that when the next heartbeat occurs the Leader would start sending chunks from the beginning.

Change-Id: I0d5f0a4230209856ecf9bcef46220ae348f52b5d
Signed-off-by: Moiz Raja <moraja@cisco.com>
BUG 2437 - Enable snapshotting based on size of data in the in-memory journal

- Changed RaftActor to snapshot based on the transaction count or the size of the
  data in the in-memory journal whichever comes earlier
- The size of data that is used is the rough (not-accurate) size of the Payload
  in the Replicated log entry
- In ShardStats exposed another property which is the data size of the in-memory
  journal
- The snapshot data threshold percentage is configurable using the config sub-system and is
  set to a default of 12%. The reason for setting it at 12% by default is because we have
  a total of 8 default shards out of the box. I could have set this to 16% as toaster is not
  a "real" data shard.
- The snapshot data threshold is calculated as a percentage of the Runtime.totalMemory()
  which is the total memory the jvm considers available for object allocation. From testing
  it appears that the total memory is what would appear in jconsole as the committed memory.

I have not added any unit testing for this - but tested this using the scenario described in
bug 2437 and it seems to work pretty well. The deployment used only 2G of memory and worked
fine for a 7 switch topology and I observed that it had not run out of memory after more than
2 hours.

Change-Id: I09ec0827c0411c42a9224bb6d159d5590c22e20b
Signed-off-by: Moiz Raja <moraja@cisco.com>