No updates for dirty keys

[meyerdan]

When an update for a particular key is scheduled via the log work buffer, no further updates can be accepted for that key until this update either succeeded or failed.

Notes:

• The update "succeeded" means that a) the log entry has been written and b) the corresponding indices have been updated.
• The pipeline needs to "stall" until the update has been processed downstream

[ThorbenLindhauer]

Remaining discussion points:

• When using a dispatcher in pipeline mode, the order of subscriptions is relevant. When we bootstrap the broker, we have subscriptions forthe log appender, request workers and index writers. The order is implicit in the code and could change without notice when we refactor something. I'd like to have that clear in one place.
• I did not yet add the isMarkedFailed flag to the BlockHandler interface, such that block handlers always receive blocks where all entries are marked as failed or not. I postponed this since we don't need it yet and I wanted to get this issue done.
• I don't really like the changes I made to the log (https://github.com/camunda-tngp/log/commit/2d2fefcbe5251c01e7952806c0be98582181c976). Perhaps there is a better solution.

[ThorbenLindhauer]

Discussion regarding point 1:

When creating a dispatcher, it must be possible to statically define subscription stages. Stages are in order, i.e. all subscriptions of a certain stage are notified before all subscriptions of the following stage. When a subscription is created, a stage must be chosen. This way, the order of subscriptions is made explicit.