`network-controller`: Capture and keep status of network updated as requests are made

Nobody has claimed this yet.

## Problem

With the new changes to both clients, we now refresh the status of the network whenever the user loads the client for the first time or switches networks. However, if they do not switch networks, it is still possible for a user to see a banner indicating that a network is degraded or unavailable when it is not the case.

Clients should have an always-up-to-date status of all enabled networks. To enable this we need to make some changes to NetworkController.

## Acceptance Criteria

- `networksMetadata.status` within NetworkController state should always reflect the current status of the network and be updated as requests are made through the network.
- `networksMetadata.status` should begin at `unknown`, then progress to either `available`, `unavailable`, `blocked`, or `degraded`.
- The status should be `blocked` when the last request responds with an error that indicates that Infura is blocking the user.
- The status should be `degraded` when the last request responds in more than 5 seconds, or responds with an error such that the retry policy gives up.
- The status should be `unavailable` when the last request breaks the circuit.
- When the network is switched, `networksMetadata.status` should revert to `unknown` initially.
- If the status is changed to `unavailable`, `degraded`, or `blocked`, then we should include details under `networksMetadata.statusDetails` (otherwise it should be cleared).
- If we have an error, then some part of it should be serialized in state under `networksMetadata.statusDetails.error`.
- If the error is an RPC error we should capture the `code`. If not an internal error, we should capture the `message`.
- If the error is not an RPC error we should reframe it as one, and follow the previous rule.
- If the status is `degraded` and we do not have an error but the last request was merely slow, then we should capture `isSlow: true`.
- `networksMetadata.statusDetails` should be reset per request.
- `networksMetadata.latency` should capture the latencies of the last 5 requests (so that they can be averaged).

Start in NetworkController and trace how requests update networksMetadata, including status, statusDetails, and latency. Verify the request outcomes and network-switch behavior against the acceptance criteria, including the five-request latency history and serialized error details.

Written by the indexing model from the issue text.