EL: optional second IPC socket so consensus eth_call is not starved by public RPC

[MitkoTschimev]

Problem

Public HTTP/WS and arc-consensus share one Reth EthApi, so they share one eth_call semaphore (--rpc.max-blocking-io-requests, default 256).

When client eth_call fills that queue, consensus get_signing_validator_set waits, then ETH_DEFAULT_TIMEOUT (1s) kills the CL. A second IPC path on the same EthApi does not help: the semaphore is per API, not per socket.

Proposal

Add --consensus-ipcpath. When set, execution opens a second jsonrpsee IPC on its own EthApi (16 blocking-io permits) and serves eth_* plus reth_subscribePersistedBlock there. Consensus points --eth-socket at that path. The Engine API on --auth-ipc.path is unchanged.

Leave the flag unset and consensus keeps using --ipcpath. Default behavior does not change.

A reference implementation is on the closed pull request #456 (closed by the contribution gate before review). I will resubmit it with Closes: #<this issue> only after assignment.

Request

Please assign this issue to me so I can open that pull request under the contribution policy.

[sergio-mena]

@MitkoTschimev thanks for your contribution. An internal ticket was raised on this: how to make queries coming from arc-consensus functional in the presence of a flood of external queries to arc-execution. We are discussing internally and will post any updates on this issue.