feat: Accept multiple consensus client endpoints

[aminsammara]

Received feedback from provers: they want to use multiple endpoints for the consensus rpc as fallback in case one goes down. We already have this for the execution rpc.

[natebeauregard]

@aminsammara Are there any concerns with backwards compatibility with this change? Should I leave the existing L1_CONSENSUS_HOST_URL env var as is or would it be fine if I updated it to be L1_CONSENSUS_HOST_URLS and then require nodes to reconfigure?

[natebeauregard]

@aminsammara As a follow up question, will we also want to modify L1_CONSENSUS_HOST_API_KEY and L1_CONSENSUS_HOST_API_KEY_HEADER to be lists that correspond to the same L1 consesnsus client index in L1_CONSENSUS_HOST_URL? I know you mentioned that the API key values weren't used too often so I wanted to double check before implementing lists for those values as well.

[aminsammara]

@natebeauregard this is a non-protocol change so i'm comfortable with having nodes reconfigure.

The two ways to use this should be:

1. An operator provides three lists of endpoints. The i'th value in L1_CONSENSUS_HOST_URL is concatenated with ith value in L1_CONSENSUS_HOST_API_KEY and ith in L1_CONSENSUS_HOST_API_KEY_HEADER, and so on.
2. An operator provides a list of endpoints in L1_L1_CONSENSUS_HOST_URL.

If that's not clear lmk