improve(BundleDataClient): Support pre-fills

[nicholaspai]

Motivation

Support use case that will become frequent once deterministic relay hashes go live where a fill precedes a deposit in real world time.

Update #1:

I'm not even sure there is a problem with refunding pre fills that occur near the end of a bundle (that precede a deposit at the beginning of the following bundle) because bundle end blocks are currently set to lag HEAD on all chains. Additionally, the bundle data client takes into account all deposits, even those right near HEAD, when validating fills. So unless the fill precedes the deposit by more than the bundle end block buffer then there should be no issue.

Problem

This opens up the possibility that even with a SpokePoolClient.query lag applied on all chains, there is a very unlucky situation where a fill is sent at the end of one bundle block range and a deposit is one of the first events in the next bundle block range. Currently, the dataworker would never issue a refund for the fill.

There are two ways around this I think and one is very complex to implement while the other is simple but increases relayer repayment latency and puts responsibility of how early to-prefill on the relayer:

1. BundleDataClient will need to "remember" which refunds it has already issued. It can do this easily using the arweave client though this increases dependencies on Arweave. Additionally, it will be quite complex to implement the most efficient data structure. I don't love this approach because of the tradeoffs of the following approach.
2. Increase the buffer that a fill must follow its destination chain HEAD block before the dataworker attempts to repay it. This additional buffer converted to seconds becomes the maximum amount of time that a fill can precede a deposit. I think this can be to something reasonable like 10 minutes assuming that pre-fills are only used by fillers who can guarantee somehow that a deposit lands on-chain when they want it to. Therefore the filler should be able to send a deposit after a fill in under 10 minutes in all cases.

[nicholaspai]

I imagine to start we'd define a hardcoded value for this fill buffer. Technically it would need to be in the UMIP so it might even have to be a config store variable...

[pxrl]

@nicholaspai I've been working on the UMIP and I'm wondering if we can get away with an even smaller change for this. So far I think it's feasible to just resolve these old fills via binary search, assuming that we won't be flooded with them. For this we'd also need to ensure that the proposer only ever considers deposits that also occur within its current proposal block range (i.e. so it should not consider deposits that come after).

I'm hopeful that it'll work OK but it needs some pressure testing.

UMAprotocol/UMIPs#611 (comment)