Filter empty sponsors

[bdrhn9]

Closes #309

I implemented this feature differently than what was suggested in the related issue. The reason behind this choice is primarily to optimize memory usage and expedite the overall process. The suggested implementation would require to keep all non-funded sponsors in memory, necessitating an iteration over them to filter out the unfunded sponsors using the isFunded attribute in each update cycle. My implementation, in contrast, is quite straightforward. It identifies funded sponsors at the beginning of the program, updates the config.triggers.dataFeedUpdates state to include only those funded sponsors, and allows Airseeker to perform its tasks as usual. Tho, if suggested approach makes more sense to you, please let me know. I'll quickly switch over.

Additionally, to leverage Promise.any, I updated version of ECMAScript from 2020 to 2021.

[acenolaza]

So if I understood this correctly:

1. Burak suggested checking the balance of the sponsor wallets and store them in memory when iterating over the triggers from config.
2. Bedirhan suggested checking the balance of all sponsor wallets before iterating over the triggers and filter out all triggers for which the sponsor wallet has a balance of zero.

I think both approaches are valid and at the end of the day, both require the same amount of RPC calls (which is what concerns me the most). I guess option #2 might be slightly easier to merge with currently being tested multicall branch. Also option #2 might make it easier to batch all rpc calls if that's ever supported by ethers.js (or by calling a contract that checks the balances of multiple EOA).

[bbenligiray]

2 also has the advantage of having been tested for a while now

option api3dao/airseeker#2 might make it easier to batch all rpc calls if that's ever supported by ethers.js (or by calling a contract that checks the balances of multiple EOA)

Good point, Api3ServerV1 inherits ExtendedSelfMulticall to enable that. I created api3dao/airseeker#406

[bdrhn9]

So we are going with the solution 2? If so, this PR is surely ready to review. Thank you both for your comments :)

[acenolaza]

Just an idea but shouldn't we merge this function into initializeSponsorWallets since we are already iterating over the sponsor list from triggers? This way we will also avoid deriving the private key for wallets that might not be going to be used.

[bdrhn9]

Ah, it'd be great but we need to use these private keys while deriving sponsor wallet addresses here. So initializeSponsorWallets process is needed to be done before filtering. But we can also prune state.sponsorWalletsPrivateKey here.

[acenolaza]

With the minor change suggested here I think this LGTM 🔥