Fix idempotent writes for cases where events have not yet been replicated

[shaan1337]

The following scenario can occur in a cluster (let's assume a 3 node cluster in this example):

• Client tries to write an event A
• The master receives event A, write it locally which is replicated and waits for commit acks from slaves
• Both slaves go down at approximately same time and a quorum number of commit acks are never received by the master (in a 3 node cluster, one commit ack from a slave would be enough)
• Client sees a timeout and tries to write event A again
• The master sees it as an idempotent write and immediately replies success although the event has not yet been replicated.
• If we elaborate the scenario further more and assume the master then goes down and the two slaves come up and form a cluster, this event will be lost since the original master will truncate when rejoining the cluster.

Proposed fix (in commit a0533bc)

• Before returning CommitDecision.Idempotent, verify if the event has been committed to the index (which is an indicator of whether the write has been replicated: as from v4.1.0 events are committed to the index on the master only when enough commit acks have been received to prevent dirty reads from the master)
• Otherwise, return a new decision: CommitDecision.IdempotentNotReady
• Handle CommitDecision.IdempotentNotReady by just dropping the write and wait for the client to try again.

Tests
Several tests have also been added around idempotency.