Blocks downloaded from peers undergoing reorg are treated as extending canonical chain and fail to import

[dmitry-markin]

The issue was reported by @rahulksnv in #493 (comment) and the test demonstarting it was added in #1999.

Example scenario:

1. Node has finished downloading up to block 1000 from the peers, from the canonical chain.
2. Peers are undergoing re-org around this time. One of the peers has switched to a non-canonical chain, announces block 1001 from that chain
3. Node downloads 1001 from the peer, and tries to import which would fail (as we don't have the parent block 1000 from the other chain)

Once the issue is fixed, test #1999 should be converted into the desired behavior test.

[rahulksnv]

Adding some observations to the thread:

1. We also see out of order announcements when back to back reorgs are happening, getting to the root cause would help mitigate the issue: Out of order block announcements #2036
2. The current ancestry search also seems to have similar issue, from relying on block numbers vs block hash. If the peer switches to a different fork in the middle of the search, we can end up in a state where peer.best_number/hash is not a descendent of peer.common_nummber/hash