Fall back to pessimism

By default the SegmentMK uses optimistic locking when committing changes to a given journal. This works well most of the time, but there a few scenarios when this strategy will fail. For example:

1. A large batch operation while other smaller changes are being committed.
2. Lots of concurrent changes being committed against the same journal.

In such cases optimistic locking will lead to some changes being delayed indefinitely, whereas pessimistic locking can guarantee eventual completion of all operations at the cost of potentially significantly reduced throughput. See http://markmail.org/message/dl3semmp577bnqoi for related discussion.

As a hybrid solution that attempts to combine the best aspects of both optimistic and pessimistic locking, we should make the SegmentMK fall back to pessimism if optimistic locking fails after some N attempts or X seconds.