Rotating chain state backups

[theoreticalbts]

• Dump the whole chain state to disk every maintenance interval, not just on shutdown.
• Dump into new subdirectory, then delete all but the most recent N dumps (where N is configurable but defaults to 2).

This way we will hopefully be able to replay only from the last maintenance interval in case of a crash.

On UNIX-like systems, we may be able to do the saving in a fork'ed process which dies after saving, which allows us to hide the latency of disk access (processing blocks can resume in the main process, while the in-memory chain state of the forked process never advances regardless of what the main process does, and most of the memory is shared between the two processes because most of the main process's state doesn't change quickly).

If every node dumps at the same time, this will also help us diagnose inconsistency bugs, and also allow us to serve the state file over HTTP or IPFS or something to help bootstrap new nodes.

The recovery from the recent chain crash was slowed due to several witnesses having to replay multiple times due to #492 and replay times will only increase in the future as the blockchain grows.

Note, full replay from genesis would still be necessary if we update DB_VERSION, if user is running a different plugin set, or if user is paranoid and cannot find a trustworthy state download.

A recent state download hash should be included in the binary, along with hardcoded checkpoints, and we should encourage persistent mirroring of these states.

[vikramrajkumar]

This issue was moved to bitshares/bitshares-core#142