Support multiple sequencer RPC endpoints for transaction forwarding

[brendontan03]

Summary

Support configuring multiple sequencer RPC endpoints for op-geth with automatic failover when one endpoint is unavailable. Currently, --rollup.sequencerhttp only accepts a single URL; if that endpoint fails (e.g. CDN or regional outage), all transaction submission to the sequencer fails.

Rationale

• Operators and third-party RPCs can only set one rollup.sequencer-http endpoint.
• A single point of failure: if that RPC is down or unreachable, eth_sendRawTransaction (and any other sequencer-forwarded calls) will fail for all users.
• There is no way to configure redundant official RPCs for higher availability.

Implementation

• Allow multiple sequencer RPC URLs via a comma-separated value
• Keep backward compatibility where a single URL continues to work

Failover behaviour

• When forwarding a transaction (or other sequencer RPC call) to the current endpoint fails, automatically try the next configured endpoint.
• Continue until one succeeds or all fail; then return the last error to the caller.

[ajsutton]

Supporting multiple sequencer URLs seems like a fairly user-unfriendly way of achieving reliability here. There are plenty of options to ensure a single URL remains available (e.g. Google doesn't have a backup URL) that seem like they would be a better option here.

[brendontan03]

@ajsutton This change is fully backward compatible as users can continue configuring single URLs as before. The PR simply adds optional support for multiple comma-separated URLs.

We have experienced production incidents where a single sequencer RPC endpoint failure (due to CDN issues) caused all sequencer-forwarded calls to fail for all users. Multiple endpoints with automatic failover would have prevented this user-facing outage. The implementation maintains existing behaviour for single URLs while providing reliability improvements for operators who need redundancy.

[ajsutton]

Yeah I'm not really worried about backwards compatibility, just that users shouldn't need to provide two URLs to get reliability. Having a single URL that has redundancy built in is pretty standard in the web2 world and it seems like leveraging that to provide extremely high reliability would be a better approach. Ultimately even with multiple URLs you're trying to get the data to the same sequencer so reliability has to be built into the sequencer operator's systems.

[brendontan03]

I agree infrastructure-level redundancy is ideal, but recent Cloudflare outages that took down major Web2 services prove even shared CDN layers can fail. This change adds optional client-side failover across different CDNs/regions as defense-in-depth, without replacing proper sequencer high availability.