Bound memory usage when recovering from a crash during chainstate write #10693

Now that #10148 is merged, it's possible to exceed configured memory limits for the utxo cache while recovering in ReplayBlocks. We should fix this, perhaps by making the recovery itself use non-atomic writes: #10148 (comment)

So in general this problem is not solvable: LevelDB will use a large amount of memory when reading in a large number of changes that were just written before shutdown. In particular a flush with large -dbcache may result in a temporary spike at startup afterwards when LevelDB converts the log into a table.