BUG 2486 : Optimizations for a single node cluster deployment

BUG 2486 : Optimizations for a single node cluster deployment

The Clustered DataStore maintains an in-memory journal which contains
a list of modifications that were made to the underlying in-memory
data store. In a system with many transactions this journal will grow
and use up a lot of memory. This is what happens when we have a high
frequency writer like StatisticsManager.

The whole reason for maintaining an in-memory journal is for replication.
Recovery for the most part requires only the disk journal.

Since memory used by the in-memory journal grows dramatically it needs
to be trimmed occasionally. We do this trimming via the snapshotting
mechanism which both trims the journal and creates a snapshot on disk.

When we do not have replication on, i.e there are no followers for a
Shard there is no need for us to maintain this in-memory journal. This
patch adds an optimization in the RaftActor where if a RaftActor(Shard)
has no followers any entry that is persisted to the journal is immediately
removed by snapshotting. However since the only reason we are snapshotting
is to trim the log we do not need to go through the usual snapshotting
mechanism which creates a serialized version of the state in in-memory
data store and then writes it to disk. So, this patch does a further
optimization by fake snapshotting. Fake snapshotting just increments the
snapshotIndex in the in-memory journal - this helps when occasionally
we do the real snapshotting.

When we have no replication and no persistence a further optimization
can be done which is to completely ignore writing (or) maintaining an
in-memory journal. This means that when a commit comes through we
immediately apply the modification made by that transaction to the
state.

With these optimizations in-place the memory usage of the controller is
well in-line with what one would see with the in-memory data store. The
performance will not quite be there because of the additional queues
and executors that a Clustered Data Store transaction has to go through.

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