Proper hardfork transition to follow with the magic header numbers upgrade

[defich]

Proper hardfork transition to follow with the magic header numbers upgrade

[monstrobishi]

As this change is to the network level protocol, I propose that block height is not used to determine whether we send the old or new magic header version. Instead, we control the release over 3 iterations, and ensure everyone has had enough time to upgrade before pushing a final release that only accepts the new magic headers.

This would make the tasks look like:

• Release one: accepts both old and new magic numbers, sends out old numbers
• Next HF, Release two: accepts both old and new magic numbers, sends out new numbers
• Next HF, Release three: accepts only new magic numbers, sends out new numbers

Let me know your thoughts

[uzyn]

Tasks:

• Parse: accepts both old and new magic numbers.
• Communication emission: sends out old numbers if before HF block; sends out new numbers if >= HF block
• 1-2 month after HF took place, take out the parsing of old code entirely. [code maintenance]