Ideally we would only rollback the state when we had a hard shutdown in
the middle of a flush but since the underlying db also has a cache that
might not write our flushing state if there's a hard shutdown, we might
not be able to detect that we shutdown in the middle of a flush. So to
make sure we always restore properly we will always rollback the
blockchain when the state is inconsistent.

We hit a bug with the following setup. Block 559307(a) was mined
creating a new utxo (u). An alternate block 559307(b) was mined which
did not create u. Subsequently 559308 was mined on top of b which did
create u again. So during the reorg u needed to go from unspent to
spent(removed) when block a was disconnected, then
back to unspent again when block 559308 was connected. However, the
utxocache commit() function did not have the ability to override a utxo
previously marked as spent back into an unspent state and thus u was
left marked as spent. When 559309 was mined spending u, it failed to
validate because u was erroneously marked as spent already.

This commit patches the commit() function to allow overriding from spent
to unspent.

This fixes a couple bugs in the UTXO set reconstruction code.
Specifically the roll forward starts one block too early resulting in a
UTXO missing error.

Also it was missing a break from the final rollforward loop which caused
it to remain stuck forever.

In this commit, we pre-allocate our cache to hold the maximum number of
entries possible. We do this for two reasons:

  1. Go maps do not shrink when items are deleted from there, so we'll
  end up with a map of this size anyway.

  2. By doing our large allocation, we avoid doing many smaller
  allocations causing more GC pressure as we ramp up to our max cache
  size.

To estimate the max size of the cache, we use the length of a p2pkh
script since they're larger than p2wkh scripts, and p2wkh isn't as
widespread yet.