Change handling of fetching events to reduce RPC calls (especially on L2's)

[jacobmakarsky]

What

The current usage of a .on listener can hammer the RPC on L2 chains with eth_getLogs requests, as it seems to make a request per block, and commonly cause 429: Too Many Request errors. The polling logic is hosted inside the ethers dependency, and is harder to modify as it would require patching.

Why

This enhances the fetching of new events to only make a set amount of requests every X interval, with X being modifiable per chain as different chains have different block creation times. RPC calls, especially to eth_getLogs, should be greatly reduced for all chains, but especially for chains that produce multiple blocks per second.

How

• Use queryFilter and a spaced out polling mechanism to request all new blocks created after X amount of time (polling function).
• Allow for different interval times per chain, depending on common new block creation time, as making RPC calls to fetch new events before a new block exists is useless
• Allow private function scanAllEvents to take either 1) a unique event param for requesting specific new events (which does not require further decoding), or 2) no unique event param passed and fetch all new events in a specified block range (which then requires decoding)
• Centralize the fetching logic to scanAllEvents
• Fetch already decoded events that are easier to handle, instead of decoding locally after fetching all events using a * request

EDIT: The PR now simply uses JsonRpcApiProvider type, which allows for using a WebSocketProvider that uses eth_subscribe to listen for new events. This is better than custom polling using queryFilter, as events are only reported once they exist, instead of queryFilter calls on interval.

[jacobmakarsky]

The failing test Should revert send, but keep fees for failing cross contract call passes locally on each test run for me, including with .only. Have not yet reproduced the failure locally.