feat: optimize jitter factor calculation

[aeddi]

This PR modifies the backoff calculation in two ways:

1. The jitter factor is now calculated based on a percentage of the interval and then added to the interval. Specifically, the jitter will be plus or minus 10% of the interval duration (so in the case of a 1s interval, the jitter will be a random duration between -0.1s and +0.1s, and the sum will therefore be a duration between 0.9s and 1.1s). The jitter is capped at a maximum of 10s (so in the case of a 5m interval, the jitter will be a random duration between -10s and +10s, and the sum will therefore be a duration between 4m50s and 5m10s).

2. The jitter factor is applied to the interval even when it has been capped at the maxInterval. Therefore, the following call ⁠calculateBackoff(10, time.Second, 10*time.Minute) will return a duration between 9m50s and 10m10s instead of consistently returning 10m as before.

Fixes #3621.

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 The pull request was created from a fork (head branch repo: aeddi/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[codecov]

Codecov Report

Attention: Patch coverage is 90.90909% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
tm2/pkg/p2p/switch.go	90.90%	2 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[zivkovicmilos]

Clean 👌

#0: 931.627978ms
#1: 2.174257897s
#2: 3.757571214s
#3: 7.751274703s
#4: 15.326207363s
#5: 32.481973117s
#6: 1m5.236442173s
#7: 2m5.88950285s
#8: 4m7.178974447s
#9: 8m25.42811194s
#10: 10m1.165531942s
#11: 9m51.467254434s
#12: 10m1.91409499s
#13: 9m54.044129573s
#14: 9m54.655958142s
#15: 9m52.082631822s
#16: 10m5.809831228s
#17: 9m55.408970261s
#18: 10m0.820427954s
#19: 9m50.776101942s
#20: 9m54.162680995s
#21: 9m55.871490743s
#22: 9m50.257767184s
#23: 9m58.557184237s
#24: 10m6.159298462s
#25: 10m9.869970109s
#26: 10m9.026321693s
#27: 9m58.270476462s
#28: 9m52.066430181s
#29: 10m5.545603695s

[zivkovicmilos]

@aeddi
Can we add a simple unit test to make codecov happy, with approximate values?
Ex. 10 tries, check the ranges

[aeddi]

@aeddi Can we add a simple unit test to make codecov happy, with approximate values? Ex. 10 tries, check the ranges

I added tests that cover pretty much all the cases I think. The only line not covered is when there's an error reading from ⁠crypto/rand (and it just return an interval without jitter).
Codecov seems happy. :)

[kristovatlas]

LGTM