fix: dropping lagging pubsub subscribers

[librelois]

⚠️ Breaking changes ⚠️

• eth_subscribe(newHeads) subscribers can now be dropped when they fall behind and exceed the pending notification cap (default: 512).
• New node CLI option: --pubsub-max-pending-notifications (default 512) controls that cap.
• Operators with slow consumers may need to tune this value upward to reduce forced disconnects.

Goal of the changes

Prevent WS/pubsub backlog growth from causing connection exhaustion while preserving Ethereum reorg-compliant newHeads behavior.

What reviewers need to know

• newHeads reorg emission was refactored to stream notifications lazily instead of building Vec<PubSubResult> per event:
  • client/rpc/src/eth_pubsub.rs
• Reorg metadata fan-out now uses shared ownership to avoid repeated deep clones:
  • Option<Arc<ReorgInfo<_>>> in mapping-sync notification flow
  • client/mapping-sync/src/lib.rs
  • client/mapping-sync/src/kv/worker.rs
  • client/mapping-sync/src/sql/mod.rs
• Added backpressure protection for pubsub sinks:
  • lagging subscribers are closed/evicted when pending queue length exceeds configured cap
  • client/mapping-sync/src/lib.rs
• Added runtime configuration hook and wired it from node CLI:
  • new EthConfiguration.pubsub_max_pending_notifications
  • template/node/src/eth.rs
  • template/node/src/service.rs
• Drop logs for lagging subscribers are debug level to avoid production log noise.
• Fixed eth_subscribe(syncing) subscription lifecycle on disconnect:
  • if subscription.send(...) fails, the task now exits (return for initial send, break in loop)
  • prevents disconnected syncing subscribers from leaving a long-lived task behind
  • client/rpc/src/eth_pubsub.rs

[manuelmauro]

lgtm

[arturgontijo]

LGTM