improve(BundleDataClient): Skip queryHistoricalDepositForFill function for non-infinite expiry deposits

[nicholaspai]

This is one step toward phasing out the deposit() method which produces deposits with infinite expiries. Infinite expiries produce extra load on the off-chain systems and once we migrate all deposits to the depositV3() function we likely don't need to use the queryHistoricalDepositForFill function anymore if we have the appropriate checks in place that the spoke pool clients have loaded old enough data for a given bundle block range. This is currently done by the blockRangesAreInvalidForSpokeClients function for example here.

The second motivation for this pr is that if we execute a spoke pool upgrade like this one, the queryHistoricalDeposit() function will no longer be useful for looking up deposits with user supplied relay hashes (because we can't apply the binary search algorithm on the depositId anymore).

The goals long term IMO of the protocol should be:

• eliminate deposits with infinite fill deadlines and ultimately remove the queryHistoricalDeposit function
• in the meantime, make sure we're only using this function on infinite fill deadline deposits, which will be mutually exclusive with deposits sent with deterministic relay hashes

[james-a-morris]

lgtm - left a few comments on the code itself. But otherwise this makes sense.

I would be curious to know if this will have unintended effects in our disputer given that we're now classifying additional fills as invalid

[nicholaspai]

lgtm - left a few comments on the code itself. But otherwise this makes sense.

I would be curious to know if this will have unintended effects in our disputer given that we're now classifying additional fills as invalid

I don't think we're classifying additional fills as invalid. We're just assuming a fill is invalid if its fill deadline is not infinite and we haven't found the deposit in the lookback window. Compare that with the current logic where we try to look for the deposit using a binary search. This doesn't happen that often in product currently because usually the depositId of an invalid fill corresponds to a legit deposit, but the fill is wrong for other reasons

This PR actually doesn't improve performance that much currently but I think it could be very important after an upgrade like this one which will make the queryHistoricalDeposit() function useless for looking up deposits with user supplied relay hashes (because we can't apply the binary search algorithm on the depositId anymore).

[james-a-morris]

I've left a few nits but otherwise LGTM