Add backoff recovery strategies

[sansmoraxz]

Can choose among various backoff strategies (fixed, lineal, exponential)

Current way of adding is marked deprecated (instead of introducing a breaking change). To replicate current behaviour use fixed strategy.

The entire recovery process is still opt-in. Except that the basic constructors now uses exponential recovery. (TCP in 10ms range, and serial plays in 100 ms range).

Fixes: #127

[sansmoraxz]

Regarding UDP not entirely sure if it makes sense to have recovery.

[alexjoedt]

Hi, thanks for the PR, lots of careful work here! Before we go further, a few questions, and some honest thoughts on direction.

1. What failure did you hit? What real problem did the current LinkRecoveryTimeout / ProtocolRecoveryTimeout not handle? A concrete example would help a lot.

2. The new defaults in NewTCPClientHandler (and others) change behavior for existing users. Was that intended?

To be upfront about where we stand: we'd really prefer to keep backoff strategy out of the library. Backoff is an application-level decision, and the caller is the only one who knows the right answer. Most people poll Modbus in a loop with their own timing, someone polling every second wants to fail fast and move on, not get stuck in a 30s backoff inside the handler. Baking exponential growth and fixed constants (10ms, 5s, 30s) into the library makes a choice that won't fit everyone, and it's a choice the caller can make better on their own.

So our preference is to keep the library thin: it manages how long to keep the transport alive, and the caller owns the retry and backoff policy. We'd like to avoid shipping a backoff framework here.

That said, we'd genuinely like to hear the problem you ran into first, it might change how we see this. Thanks again! 🙏

[sansmoraxz]

Well one of the use cases would've been a noisy wire / connector where we could just throw some basic config instead of fine tuning configs for testing etc.

Also the current strategy is more or less fixed backoff. I just thought of expanding on this into the 3 variants where it would make sense. For example, linear backoff can help prevent a storm of requests flooding a wire (when it's not fine tuned for it - or flooding a device stuck rebooting).

Regarding the defaults, TCP we can run with lower timings, but for serial (more specifically RS485) most often it's dependent on wire length and baude rate, and it's almost impossible for a recovery to succeed in the 10ms range. Infact for production we tend to run between 160 to 300 ms as that's what was most stable observed and an interpoll delay of around 80ms for voltage stablization.

Also for serial, there would only be one client holding the port (as parallel masters would conflict the timing and result in noise over the wire).

Granted all this can be externalized at an application level. Just thought that having linear/exponential backoffs would make serial communication easier to use if it's part of this lib.