[2.2] Guards for concurrent shutdown when applying batches on slaves

Committing and applying a batch of transactions in
TransactionCommittingResponseUnpacker would:
- 1. append a batch of transactions
- 2. force
- 3. then finally mark as committed and apply each one

If there would occur a clean shutdown during or after 1 or 2, but before 3
there might be transactions appended to the log, but never applied, not
even the next start of the db, since there would be no recovery performed.
A similar problem could occur for rotation where force (2) would check
rotation which would effectively exhibit very similar problems.

This commit adds synchronized using the same monitor as append and shutdown
for one whole transaction batch to guard for concurrent shutdown. Also
TransactionAppender#force (2) is changed to not check rotation, and
instead the TransactionCommittingResponseUnpacker checking rotation before
committing and applying each batch, i.e. no possibility of rotation
happening in between append and commit-and-apply.