Analyze polling chain instead of using websocket conns

[bitwiseguy]

CC: @lalexgap

The chainservice currently has two websocket subscriptions:

1. Events emitted by the NitroAdjudicator contract
2. New blocks mined by the chain

The websocket connections frequently (once every couple of hours?) receive errors causing the connection to break, and forcing the chainservice to re-establish the connection. A common error message on those connections is i/o timeout.

We should investigate an alternative approach where the chainservice polls the chain instead of relying on a constant websocket connection. The polling frequency could be set to 0.5-1x the block time to ensure the chainservice does not lag behind too much.

Pros of polling

1. Simplifies chainservice code substantially. Polling is less prone to many of the race conditions that the current implementation is susceptible to. Switching to polling would allow us to remove lots of logic currently in place to protect against race conditions.
2. Http requests seem to have a lower failure rate compared to websocket connections. If we switch to polling we could also remove code related to a workaround involving a known issue with the ethereum event subscription.
3. Http requests targeting the same RPC provider likely scale better than adding additional websocket connections to the same RPC provider

Cons of polling

1. Less performant (events will be detected later than they are on websockets). However, if the polling frequency is set to 0.5x the block time, we can reduce the maximum delay between event emission and nitro detection to 0.5x the block time (0.5 x 10sec on Filecoin = 5 sec max delay)