Add option to retain rather than truncate ledger files on rollback

[eddyashton]

Following #2192, we've discussed what we do with uncommitted ledger files on rollback. Currently the rolled back entries are deleted - a partial chunk file is truncated, and any completely rolled back chunk is deleted. There are various reasons that this behaviour may not be what the operator wants:

• It risks losing an active, correct ledger suffix from a partitioned primary, which is likely to delete this suffix on reconnection to the network.
• In complex partitions it may still be possible or desirable to reconcile ledger forks, although this is hard in the general case.
• Retaining these rolled back suffixes allows a thorough audit to trace client errors ("I see the transaction you're talking about, it happened here, but it was never committed") around elections in a way which is not possible if they are deleted.

These chunks should never need to be read by a node, but may be used and manipulated by operators.

So we need to:

• Come up with a naming scheme for these files, to distiguish them from pending and committed ledger chunks
• Modify ledger.h to create copies of these files during truncation
• Expose this behaviour as a configuration option to operators, who can at least disable this (and keep the current deletion behaviour) to minimise disk use, and potentially configure the location where these files are stored

The files need some per-rollback unique ID, since it is possible to have multiple rollbacks for the same index range and we want to keep them all. The obvious solution here is to use the view in the filenames.

We've discussed several possible filename suffixes, trying to describe precisely what these files contain while making it clear that they're non-critical for normal ledger operation. The current favourite is .rolled_back.<view>.<seqno>, so an unlucky ledger directory might look like (sorted by last-write time):

# Some early state was committed
ledger_1-3.committed
ledger_4-8.committed

# There was a rollback at 2.10, when the current index was at 21 and had
# produced 2 complete-but-uncommitted chunks and a partial chunk
ledger_9-12.rolled_back.2.10
ledger_13-18.rolled_back.2.10
ledger_19.rolled_back.2.10

# There was a second rollback at 3.10, when the current index was at 15
ledger_9-12.rolled_back.3.10
ledger_12.rolled_back.3.10

# There was a third rollback at 4.12, when the current index was at 13
ledger_9-12.rolled_back.4.12
ledger_12.rolled_back.4.12

# The network healed and commit state advanced again
ledger_9-12.committed
ledger_13-24.committed
ledger_25

If anyone has thoughts on this naming scheme (better terms than rolled_back, parsing/sorting problems with the element order), please discuss them below.