Reject GetBlockHeaders requests while importing blocks with possible fork

[grbIzl]

Purpose:
This PR aims to fix the following scenario

1. There are two connected nodes A and F
2. Sync is going up to block N for both nodes
3. Node F receives new canonical subchain starting from N block (blocks N' and N' + 1)
4. Before starting new subchain's import node F sends broadcast about new blocks (this notification was introduced by @tomusdrw in his Improve block and transaction propagation #9954 )
5. Node A receives notification about new block N' + 1, sees, that it has unknown parent.
6. Node A starts retraction in order to find the beginning of fork, requesting headers for blocks N, N-1, N-2, N-3 etc from F
7. Meanwhile node F has not completed import of N' and N' + 1 blocks yet and replied to all requests from A with previous blocks (up to N)
8. Node A quickly runs into N - 128 block (128 is the limit for number of requested headers)
9. Node F finishes new blocks import
10. Unfortunately retraction on node A went too far already and A requested 128 headers beginning from N - M block, where M > 128. As a result F returns old 128 headers without new N' and N'+ 1
11. As node A doesn't receive new blocks N' and N' + 1, it continues retraction to 0.
12. Sync stops.

Comments to the scenario.
This problem is reproduced on configuration from #10724 when A and F run locally on one machine and A is only connected to F (F connected to the whole mainnet). As a result, network latency between A and F is low and A can quickly descend down to N - M block to the stuck condition. For regular configurations stuck is less likely but it still causes overhead by sequences of GetBlock requests emitted by nodes, trying to find the common parent in such situation.

Solution.
I suggest (with help of @arkpar ) to break this sequence on step 7 on node F. And do not reply to GetBlockHeaders request, if there is a suspicion, that node is currently importing a block, that can cause reorg. In order to define this condition, I check block verification queue and look, if there is a block there, that has current best block as a parent. If there are no such block processing, I assume, that the queue has block with fork, and node should not reply to GetBlockHeaders. Also I used empirical limitation for queue size and assume, that if it's longer, than 8 elements, it doesn't contain fork block.

It's the second part of #10864 because this problem was masked by #10864, so these PRs should go together.

[dvdplm]

@grbIzl is this PR still relevant?

[grbIzl]

@grbIzl is this PR still relevant?

I'll put this PR on ice. If we are not able to verify it in the following weeks, I'll prefer to close it.

[grbIzl]

The fix is verified. I'm closing this PR in favor of newly created #11265 with clear history of commits.