WebSocket auto-reconnect and resilience for production bots

[koko1123]

Motivation

Production bots (liquidation keepers, arbitrage searchers, MEV-Share listeners) run 24/7. The current ws_transport.zig has no reconnection logic — a dropped connection kills the bot. This is a blocker for using eth.zig in any production searcher.

Required behaviour

1. Auto-reconnect on disconnect: Exponential backoff with configurable max delay (e.g. 100ms → 200ms → 400ms → ... → 30s)
2. Re-subscribe on reconnect: Subscriptions registered via subscription.zig should be automatically re-established after reconnect
3. Missed event detection: After reconnect, caller can optionally request events since last-seen block to avoid gaps
4. Connection health monitoring: Optional heartbeat (ping/pong) to detect silently dead connections before the OS timeout

API surface

pub const ReconnectOpts = struct {
    /// Initial backoff delay in milliseconds. Default: 100
    initial_backoff_ms: u64 = 100,
    /// Maximum backoff delay in milliseconds. Default: 30_000
    max_backoff_ms: u64 = 30_000,
    /// Maximum reconnect attempts (0 = unlimited). Default: 0
    max_attempts: u32 = 0,
    /// Send WebSocket ping every N ms to detect dead connections. 0 = disabled.
    ping_interval_ms: u64 = 0,
    /// Callback invoked on each reconnect attempt.
    on_reconnect: ?*const fn (attempt: u32) void = null,
};

Why this matters for the MEV use case

A liquidation keeper that monitors positions near threshold needs continuous WebSocket connectivity. Missing a single block where a position crosses the liquidation line means losing the fee to a competing bot. Reconnect logic is table stakes, not a nice-to-have.

Implementation notes

• Reconnect logic can live in ws_transport.zig as a ReconnectingWsTransport wrapper, keeping the base transport simple
• The reconnect loop should run on the same thread (no OS thread spawning required — caller controls the event loop)