Drain blocks on peer disconnect

[arkpar]

Two issues fixed here:

1. After Update common block in sync after importing blocks of a peer, please read UPDATE #7733 peers may enter common block/ancestry search mode when common block is detected to be too far behind. However this should not be happening when major sync is in progress. I've added a check for that.
2. Peers starting common block search in the middle of the major sync resulted in common block being a bit behind of the import queue, which leads to duplicate requests and bans.
3. Since we only drain downloaded blocks on new block data, a canceled duplicate request at the front of the download range may result in stalemate situation, where we don't issue new download requests because the block container is already full and we don't drain the block container because there are no incoming blocks. To fix that I've added a check for blocks that may be imported after a peer disconnects and their download request is cleared.

[tomaka]

Not an expert in the sync code, but looks good to me

[bkchr]

Unfinished comment.

[bkchr]

Does this means we are waiting until all blocks are downloaded, even if we have send the same request multiple times to different peers?

No, in case of parallel requests, as soon as we download a block all other requests are made obsolete. Normally when doing major sync, we don't issue parallel requests though. Duplicate requests come from issues 1 and 2. We try to download blocks that are already queued, and while the request was active, import queue made some progress. So a call to drain would discard the block that are already imported.