Fix forward sync may stuck on slow peer

[asdacap]

• Fix forward sync stuck on slow peer as it will keep picking peers with speed, which will always be one as only one was tried.

Changes:

• Modified BySpeedStrategy to pick peer with no speed as long as number of peer with known speed is less than 5.
• Modified BlockDownloader to not cancel current download immediately. It will continue processing downloaded blocks before checking if a better peer is available.

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Other (please describe):

Testing

Requires testing

• Yes
• No

In case you checked yes, did you write tests??

• Yes
• No

Comments about testing , should you have some (optional)

• About 24 to 32 mainnet smoke tests. None stucked on slow peers.

Further comments (optional)

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[asdacap]

Piggibacked this on several smoke tests for consistency. 32 mainnet runs probably. No run stucked on slow peer.

[MarekM25]

why do we need retry?

[asdacap]

The logic is random, already have margin of error, but sometimes it still fails.

[MarekM25]

Looks ok. It would be great to sync pre-merge node/nodes too. For example, gnosis. We should check engine API hive tests too. I would consider running it with higher pruning cache to see how node will recover after timeout.

[asdacap]

All hive test passed.