fix: prevent exhausting failover providers on erc165 reverts

[eli-lim]

Background

1. I noticed slowness when checking my degree on the site - took about 4 - 5s to verify
2. Looking at the networks tab, I noticed it was making a bunch of requests to different public node providers in sequence

SR-compressed.mp4

Root cause

1. oa-verify is checking if the documentStore supports some interface, compliant with the ERC165 spec.
2. When the rpc call returns execution reverted, ethers will throw an error. oa-verify mitigates this with a try-catch, returning false if an error is thrown.
3. Unfortunately, website's OAFailoverProvider catches this deeper in the call stack (rendering the try-catch in (2) moot), and moves on to the next provider, until the list of providers is exhausted.

TLDR:

async function isBatchableDocumentStore(): boolean {
  try {
    // this is expected to throw if erc165 is not implemented, but it keeps retrying instead
    return await OAFailoverProvider.perform('call', { contract, erc165Check }) as boolean; 
  } catch (e) {
    return false;
  } 
}

Fix

1. (This PR) Stop the OAFailoverProvider from overzealously retrying on erc165 reverts. It can also be made more generic, to stop retrying on any call exception.
2. (Optionally) switch to use public node providers with lower latency

   Ignoring other concerns like privacy / agreements with the existing node providers.

Doing these:

Screen.Recording.2024-10-30.at.2.36.18.AM.mov

Note

An alternative is to change oa-verify to use a direct rpc call, to bypass ethers's throw-on-revert

[HJunyuan]

@eli-lim Thank you for proposing these improvements!

I've made a few minor suggestions before we proceed to merge this PR in.

[HJunyuan]

Suggested change

	return false;
	throw error;

[eli-lim]

actually the point of this is to not throw on call exceptions