Improve retry logic and update unmaintained dependencies for Rust lint CI

[barshaul]

PR Description:

This PR enhances the retry strategy and addresses dependency maintenance issues in the Rust lint CI:

• Replaced Unmaintained Crates: Removed the backoff, tokio-retry, futures-time and Derivative crates due to limited functionality and lack of maintenance. Previously, the project used both backoff (unmaintained) and tokio-retry (last updated 3 years ago). These have been replaced with tokio-retry2, which offers enhanced features for exponential backoff. Additionally, Derivative was removed as it is no longer maintained.

• Improved Retry Functionality: The new tokio-retry2 crate includes better jitter control, ensuring consistent exponential backoff intervals without erratic timings. The previous implementation produced inconsistent retry intervals (e.g., 192ms, 110ms, 900ms). With tokio-retry2, the jitter range is controlled, maintaining a steady exponential backoff. For slot refresh retries, the strategy has been updated to ExponentialFactorBackoff, resulting in attempts with intervals such as [0ms, 400-600ms, 800-1200ms].

Issue link

This Pull Request is linked to issue (URL): closes #2669

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one issue.
• Commit message has a detailed description of what changed and why.
• Tests are added or updated.
• CHANGELOG.md and documentation files are updated.
• Destination branch is correct - main or release
• Commits will be squashed upon merging.

[eifrah-aws]

How did you come up with these numbers?

[barshaul]

Till now, the jitter range was (0,1). This change reduces the range to 20% above and below the interval, which is sufficient to spread requests across different time slots from various hosts, while maintaining increasing intervals

[avifenesh]

Why do we need to use the counter and not the built in limiter? Is there a reason we need to use the number down the tree?
If it can be changed and managed in one place it will reduce complexity.

[barshaul]

We use the retry number internally to calculate topology to know if we're at the last try - and if we are, we have less restrictions on choosing the topology view

[barshaul]

Note the we don't use it as a limit anymore, only for the sake of choosing the topology.

[avifenesh]

I see I tried to see if there's a way to call something different on last try. It appears that the only callback is notify, which can be used, but it's not the reason it exists, so probably not a good idea.
In general, I would prefer the called function to have one logic, and the caller to call functions base on needs, so we keep functions shorter and more readable. That's why I want to avoid the counter logic.
But couldn't find a replacement currently.