provider proxy

[Keyrxng]

Resolves #235

Wrapped app.provider in a Proxy to catch any failed call across the app

QA:

You see two page loads that require the proxy to select a new provider and retry, the third requires no retry.

You see two sets of logged failures because the app makes a call on page load, this cannot be effectively removed as a successful RPC will not need changed as seen on the 3rd page load. The proxy uses the first stored RPC and then loops the latencies retrying until successful.

0601.mp4

[ubiquity-os-deployer]

e299b2f

bddfb34

021bc75

[github-actions]

Preview Deployment
e299b2f552c4ef96146d9b7e43183685fd70643a
bddfb34701d9dba785b34186a841707a0f8ee293
021bc75fb6ba080b6d9b87dbcc6997c2efde3edc

[Keyrxng]

I wasn't able to really understand why they were failing in the first place but in manual testing this approach resolved the issue every time.

I will add some tests to cover it, I'm unsure how well Cypress will be able to test it so it may have to be with Jest

---

I was thinking maybe to just use the ethers.providers.FallbackProvider and have each latency entry as a node but that has it's own array of potential errors to handle

[Keyrxng]

@rndquu should this be closed or used as a stop gap until rpc-handler has been updated?

[rndquu]

@rndquu should this be closed or used as a stop gap until rpc-handler has been updated?

I think it makes sense to close this PR, wait for ubiquity/rpc-handler#23 and then update the code in this repo accordingly