DB v1->v2 migration

[antiochp]

Resolves #3043.

On startup reads all the full blocks from the local db and writes them back into the db using protocol v2.

We take advantage of the blocks iterator and simply attempt to read them in v1.
Subsequent reads will fail quickly (v2 reader will not successfully read v1 data) causing the iterator to terminate early so can be safely run multiple times.

Note: This PR is overly noisy right now as it is based on the branch for #3034.
Once #3034 is merged this PR will be rebased against master and should look a lot cleaner.

[antiochp]

@DavidBurkett You suggested storing the db version somewhere so we easily know which version a particular node is using for its db.

I played around with doing this but decided this was not necessary right now. It may be something we want to introduce at a later date once versioning gets more complex (right now its just blocks and a simple old v1 vs. new v2).

Currently the rules are simply -

• check if we have v1 blocks in the db (by attempting to read them via v1 deserialization)
• if so, migrate them all to v2 and continue
• a running node will always be in v2 (after the above migration)