feat(discovery): Implement capped linear backoff and asynchronous tri…

[nodersteam]

Implemented a capped linear backoff mechanism to reduce the frequency of retries during the discovery process. The backoff starts at 5 seconds and increases by a factor of 5, capped at a maximum duration of 10 minutes.

Added asynchronous triggering of the discoveryLoop using the triggerDisc channel

#2703

[codecov-commenter]

Codecov Report

Merging #2766 (ea4a70c) into main (849cb67) will increase coverage by 0.06%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##             main    #2766      +/-   ##
==========================================
+ Coverage   51.92%   51.98%   +0.06%     
==========================================
  Files         161      161              
  Lines       10827    10831       +4     
==========================================
+ Hits         5622     5631       +9     
+ Misses       4710     4705       -5     
  Partials      495      495              

Files	Coverage Δ
share/p2p/discovery/discovery.go	76.25% <88.88%> (+0.40%)	⬆️

... and 7 files with indirect coverage changes

[ramin]

@nodersteam i think baking the backoff into the ticker is the wrong approach. I'd also request splitting the two tasks (backoff, async trigger) into two PRs for ease of review if you can.

For the backoff, i'd suggest something like adding a "backoffDuration" time.Interval to the Discover struct (or even something that wraps that to apply a backoff) then leave the tick interval the same, but add/update an incrementing backup duration on d.discover failures that will be checked before executing. Will make things simpler. Also, i'd suggest adding a little jitter to the backoff interval so very slightly randomize the backoff times. Want to give it a shot?

[nodersteam]

@nodersteam i think baking the backoff into the ticker is the wrong approach. I'd also request splitting the two tasks (backoff, async trigger) into two PRs for ease of review if you can.

For the backoff, i'd suggest something like adding a "backoffDuration" time.Interval to the Discover struct (or even something that wraps that to apply a backoff) then leave the tick interval the same, but add/update an incrementing backup duration on d.discover failures that will be checked before executing. Will make things simpler. Also, i'd suggest adding a little jitter to the backoff interval so very slightly randomize the backoff times. Want to give it a shot?

yes, I will try to implement this
the comments that were left above have already been practically corrected, but I will also take into account your comment

[nodersteam]

@ramin @walldiss

Hello! What do you think about improving test logging?

I’m currently writing tests to check the correct implementation of everything I need, and I’m faced with the fact that logging tests is not informative. What do you say about this format? Or is this not necessary?

[ramin]

@nodersteam i quite like the idea of being able to see some more detailed logging if the -v flag is provided when running tests. I'd say propose it with the updates to the PR and explain why it was necessary and helpful so we can understand while reviewing.

[nodersteam]

@walldiss Is the question of continuing to search for peers after finding a sufficient number still relevant?

mean this #2703