The API throws when the directories already exist, which is quite
unexpected.
This now changes the code to silently ignore these issues in the
knowledge that the immediately following opening of files will
fail with a nice error message.
This adds a unit test to see if the combination of invalidateBlock and
reconsiderBlock do what we expect to do.
The main issue was that we store an invalidated block in the UTXO and we
forgot to re-validate that on reconsider.
Additionally I avoid writing a lot of unchanged data to the block-index.
This is done in several steps:
1. Separate my height from the remote peer heights.
Instead of assuming we have one height, recognize that a peer may
not be at the tip at the same time we are. We monitor headers/invs
to update the 'peerHeight' variable.
2. Ask for merkle blocks from a peer to the maximum height of that
peer (but not later than what we validated to be true).
This avoids us asking past the remotes tip which they didn't like.
3. Redo the SyncSPVAction to use all this and make it much more
reliable in finding peers to download from and getting all the
changes as fast as possible.
We already had in place the blockSizeAcceptLimit as the limit
on messages, which is now the only limit.
In practice this means when the operator sets the maximum mining
size that we adjust the blockSizeAcceptLimit, if they only set the
blockSizeAcceptLimit, we use that (plus a margin) to limit messages
both on the p2p layer and on the RPC (JSON) layer we change the
limit to be twice the blockSizeAcceptLimit (copied those numbers
from BCHN).
In most cases headers would be automatically downloaded if we didn't
connect to that peer for a while, but that is not a guarentee so lets
make sure we actually start downloading headers from any peer we can :)
This is a feature request following the fact that some sysops use a
symlink for the unspent dir and don't want the reindex to delete the
symlink itself.
TomZ