[snowkide]

When a node is declared unreachable, unreachableLoop always waits at least 1s before the first redial (NewRedialBackoff: min 1s, max 15s). The 1s is hardcoded and can't be configured.

For a single RPC entry behind a proxy or load balancer, a common reason to become unreachable is that the backend serving the connection restarted. A fresh connection is usually available right away, so the wait is downtime for the chain on every backend restart. With several RPC entries failover hides this; with one entry it doesn't.

This adds NodeConfig.RedialBackoffMin() time.Duration:

• It sets the delay before the first redial. Later attempts back off exponentially from there, with jitter, up to the existing 15s max.
• 0 redials immediately. If that attempt fails, retries back off starting from 100ms (the backoff library's floor for a zero min), so there is no tight loop against an endpoint that is still down.
• Other loops using NewRedialBackoff (chain ID recheck, syncing recheck, send-only nodes) are unchanged.

No behavior change by default. MultiNodeConfig.RedialBackoffMin() returns 1s, so chains using MultiNodeConfig keep the current timing. EVM exposes the value through NodePool in a separate PR.

Merge order: this adds a method to NodeConfig, so chainlink-evm can only bump multinode past this change once its NodePool.RedialBackoffMin PR (below) is merged. That PR builds against the current multinode and can be merged first.

Tests:

• New: with RedialBackoffMin zero, redials immediately and with RedialBackoffMin set, waits it before the first redial (first dial no earlier than 1s).
• Four existing aliveLoop tests that move to unreachable without a Dial mock relied on the hardcoded 1s wait; they now set redialBackoffMin: time.Second explicitly to keep testing the same thing.

Requires Dependencies

None.

Resolves Dependencies

• smartcontractkit/chainlink-evm: config: add NodePool.RedialBackoffMin (config: add NodePool.RedialBackoffMin chainlink-evm#585)