Instead of having the service take onBreak and onDegraded callbacks, we could consider having the service emit events, and emit separate events for the primary RPC endpoint vs. the failover RPC endpoints. This way clients could react to the failover status at each appropriately, and we'd also give the network controller a way to react to the status as well (if we, say, need to capture in state which RPC endpoint among a primary and list of failovers is the active one).

We could also keep things simple and make this change in #4992, whichever makes the most sense.

Leaving more notes for myself:

Currently both the fetch and Infura middleware implement retry logic. We need the service to contain this logic instead. This is different from a standard service object because some errors are retriable while others are not. This means that the RPC service needs to use a different error filter policy other than handleAll. That means that createServicePolicy needs to support passing in a custom error filter policy (defaulting to handleAll). The service also needs to check for HTTP status codes (which means we need to standardize on them), as this dictates whether or not to retry, and it may also parse the JSON response for convenience (but perhaps failing to parse the response should not trigger a retry? not sure).