Merge: add second line of defense for killing of runaway merge tasks

This prevents the following scenario:

• A merge ID is set and the merge task started
• If the merge task ends without setting merge-id back to null, subsequent merge requests will be rejected, because the merge coordinator thinks there is a merge still ongoing
• This should not happen, but I nevertheless want to add a second line of defense to prevent this

SOLUTION:

• Whenever a merge-id is assigned and the merge task started, we also keep track of the time this happened
• A separate timer task is started and runs every (say) M seconds (e.g. 2 minutes)
• The task checks whether the time stamp of the last merge (if not 0 (= no merge is running)) is more than N seconds old
• (M and N are configurable)
• If this is the case, then we force-cancel the merge
• The forceCancelMerge() operation is also exposed via JMX, so it can be invoked (e.g.) across a cluster: probe.sh op=GMS.forceCancelMerge