DHT bootnodes: rate limit the discovery attempts instead of limiting max retry count

[dmitry-markin]

Instead of giving up after 5 discovery attempts, keep retrying with a delay of 30 seconds until the discovery succeeds.

This fixes a DHT bootnodes zombinet test execution on CI where individual nodes may start with a significant delay. This will also help should there be temporary connectivity issues leading to 5 failures in a row.

[lexnv]

Looks good to me! Left a few minor thoughts on the process itself. Wondering if we could simplify a bit the state machine needed for retrying. However, that could be a followup 🙏

Im wondering if it would make sense to have an exponential timer similar to what we have in the substrate/discovery? Where we might go from 8s to 16s to 32s and cap it there? 🤔

[dmitry-markin]

Wondering if we could simplify a bit the state machine needed for retrying. However, that could be a followup 🙏

I don't think we can simplify it, because currently the state machine boils down to:

1. discovery in progress -> do nothing
2. no discovery in progress -> trigger retry in 30 seconds

Im wondering if it would make sense to have an exponential timer similar to what we have in the substrate/discovery? Where we might go from 8s to 16s to 32s and cap it there? 🤔

On real networks the discovery takes 2-3 minutes, so 8s or 32s won't make a big difference, while introducing the complexity of an exponential timer.

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/15757558286
Failed job name: fmt