feat(BundleDataClient): Support refunds for pre-fills/slow-fill-requests and duplicate deposits

[nicholaspai]

Definitions

• "pre-fill": any fill that is in a bundle that precedes the bundle containing the matched deposit
• "pre-slow-fill-request": a mouthful, and any slow fill request in a bundle that precedes the bundle containing the matched deposit
• "duplicate deposit": a deposit with the same relay hash as an existing one

Core logic for refunding pre-fills:

Evaluate all deposits in the current bundle that were not filled in the current bundle. Figure out whether the deposit was filled, by either:

• Finding the fill in the spoke pool client's memory, or
• Querying the fill status on-chain

If there is a fill for this deposit then we need to issue a refund for this fill because the fill occurred in a previous bundle where it might not have been refunded.

We need to use a similar algorithm for creating slow fill leaves for pre-slow-fill-requests with the caveat that we cannot create slow fill leaves for deposits that have expired

Non-determinism for refunding pre-fills

We don't deterministically know whether this pre-fill was refunded in the prior bundle because we don't know for certain what kind of event search window the proposer of the prior bundle used when constructing the bundle.

To illustrate this problem, imagine if a fill and a deposit are sent 10 minutes apart such that the fill is at the end of the current bundle and the deposit is at the beginning of the next. The prior bundle proposer probably would have issued a refund for this fill, but we don't know for certain.

So, one way around this non-determinism is to introduce a new rule to the UMIP:

Do not issue refunds for fills or slow fill leaves where the matched deposit is later than the current bundle block range

This rule makes it always apparent which bundle should include a refund or slow fill leaf for a pre-fill or pre-slow-fill-request.

This will require a UMIP change to this PR

findFillEvents

When we need to query fillStatuses() on-chain to detect whether a deposit corresponds to a very old pre-fill, then we also need to locate that old fill. We assume this is rare and will use the relatively expensive findFillEvents() function which is built off of the existing findFillBlock() function to locate that event.

Duplicate deposits

This PR also adds support for duplicate deposits that are possible to create with unsafeDeposit. Duplicate deposits are added to bundleDeposits for they should be included in runningBalances. Duplicate deposits can be refunded upon expiry but for all deposits, expiry refunds cannot occur once the deposit has been filled.

Due to the presence of pre-fills, we can now no longer instantly include that a deposit submitted in the current bundle that has expired is due a refund. We now need to check its relay status in the case where we don't see a matching fill in our memory.

Unit tests

Can be found here: across-protocol/relayer#2010