Do not mark peer as low quality too soon if there is only one peer connected

[kamilchodola]

In a situation where there is only one peer connected we have a logic which can very quickly mark this peer as low quality one: https://github.com/NethermindEth/nethermind/blob/d18e4f695d979060804237aae16f92488c8f8d1f/src/Nethermind/Nethermind.Synchronization/SnapSync/SnapSyncFeed.cs#L172

It is problematic especially on testing scenario where we set only 1 selected peer to sync from but can be problematic on small chains as well. Would be really nice to improve that part of code to make sure that maybe first node should update pivot and then recheck this peer once more.

[ssonthal]

Hi @kamilchodola , kindly refer this PR - https://github.com/NethermindEth/nethermind/pull/6818

Let me know if this looks good.

[ManiBAJPAI22]

Hi @kamilchodola, can you please review this PR- #7067

Let me know if this works.

[zleypner]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I’m a front-end developer transitioning to Web3, and I would love to make my first contribution to this project. I'm excited to take on this issue to challenge myself, learn, and contribute to the project's success.

I'm also a member of the Dojo Coding community, looking forward to applying my skills in this new space while I grow and contribute to the community.

How I plan on tackling this issue

To address the issue of prematurely marking a peer as low quality, especially when only one peer is connected or in small chain scenarios, I would take the following steps:

• I will add a retry mechanism that allows a peer to correct itself before being marked as low quality. This will involve rechecking the peer after updating the pivot point and then retrying the sync.

• If a peer shows signs of being low quality due to multiple failed responses, I will update the sync pivot and retry the sync with the same peer. If the peer still fails after this, I will confidently mark it as low quality.

• For scenarios with only one peer, I will implement a grace period or allow a specific number of retries before penalizing the peer. This ensures that the peer isn’t penalized too quickly, especially when it’s the only option.

-By making these adjustments, I expect to reduce the chances of penalizing a peer too quickly, improving the reliability of the synchronization process, especially in edge cases or testing scenarios.