fix(dataworker): Don't permit out-of-order block ranges

[pxrl]

Without this check, the code produces a Lisk block range of [6063320, 6063319] when validating the proposal associated with dispute https://etherscan.io/tx/0x5255006f0a66f151d6a419b876dd673f94ec85a97cd3570bc54f7def7a6422a6.

This originally arose because the primary RPC provider used for determining the latest block number on Lisk had an outage and began severely lagging the head of the chain, such that the proposer was not able to increment its end block number past the previous proposal's end block number due to the Lisk block buffer imposed on new proposals.

[bmzig]

Is this fine to do? It seems like we are permitting the block ranges to be out of order and just interpreting things differently if they are.

[pxrl]

Is this fine to do? It seems like we are permitting the block ranges to be out of order and just interpreting things differently if they are.

The block ranges specified by widestPossibleExpectedBlockRange assume that the chain's start block should increment, and the range is [expectedStartBlockNumber, SpokePoolClient.latestBlockSearched]. This code is however swapping out SpokePoolClient.latestBlockSearched for the actual end block specified in the proposal that is being validated. Therefore, if the proposer chose not to increment the block range for this chain, this can result in an incoherent range.

This is OK as far as I can tell; provided that this new check is imposed to catch the out-of-order scenario.

It's also worth noting that per the UMIP, the proposer is permitted to soft-pause the chain if it can't reliably determine a valid block range: https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-179.md#identifying-bundle-block-ranges. So the disputed proposal should actually be correct.