Fundings of multiple depositories potentially revert

[bbenligiray]

To guarantee a funding to not revert, we need to use the transaction count at the time we do the check for if we should do the funding transaction as the nonce. The current implementation in #24 doesn't satisfy this in the case of multiple depositories because we fetch the block number along with the first depository's static call, and fetch the transaction count for that block number for all depositories (this is a problem because that was not the block number at which we did all the static calls).

The only solution to this is to batch the multicalls of all depositories that the bot serves to make sure that they all happen on the same block, and then use the transaction count at that block as the nonce for the following transactions. This is not ideal, as too large multicalls are already a potential problem with even a single depository (#25), and batching multiple trees only exacerbates this issue.

The current implementation is not particularly problematic considering that we don't expect the bot to be used to upkeep multiple depositories. We have two options for the long term solution, don't care about potential reverts or have a separate mnemonic be specified per depository contract (which would be my choice).

[bbenligiray]

Come to think of it, the current Airseeker approach is simply saying "If you power multiple data feeds with a single sponsor wallet there will be a risk of reverts" and not disallowing it. The equivalent approach here would be leaving the implementation from the PR as is (because it works perfectly for the single depository case) and let the user judge the "risk" of using multiple depositories for themselves.