Use retry switching peer for world state download tasks

[fab-10]

trafficstars

PR description

Built on top of #5509, so please check it first. Link to only see diff again #5509

With this PR all the world state download tasks used by snap sync are updated to use the retry switching peer strategy, to reduce the chance that we keep sending requests to the same bad peer.

relates to https://github.com/hyperledger/besu/issues/5415 and #5271

[github-actions[bot]]

• [x] I thought about documentation and added the doc-change-required label to this PR if updates are required.
• [ ] I have considered running ./gradlew acceptanceTestNonMainnet locally if my PR affects non-mainnet modules.
• [x] I thought about the changelog and included a changelog update if required.
• [x] If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

[matkt]

Just a question. A peer that is useless for the worldstate part may not be for the blockchain part. Is there not a risk of losing valid nodes for a certain type of data by marking useless when it could still help us. For example Besu and Nethermind which do not provide Snapsync data but remain valid for the blockchain. Should not have a more complex notion of useless ?

[matkt]

testing currently the PR with my snapsync boost feature

[macfarla]

Blocked by #6609 - without that we would disconnect peers, because we are trying peers that do not serve snap data.

[jframe]

@fab-10 Closing this, reopen if think we still need it