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

Without this check, the code produces a Lisk block range of [6063320,
6063319] when validating the proposal associated with dispute
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.

src/dataworker/Dataworker.ts

@@ -734,10 +734,12 @@ export class Dataworker {
       };
     }
 
-    const blockRangesImpliedByBundleEndBlocks = widestPossibleExpectedBlockRange.map((blockRange, index) => [
-      blockRange[0],
-      rootBundle.bundleEvaluationBlockNumbers[index],
-    ]);
+    const blockRangesImpliedByBundleEndBlocks = widestPossibleExpectedBlockRange.map((blockRange, index) => {
+      // Block ranges must be coherent; otherwise the chain is soft-paused.
+      const [startBlock, endBlock] = [blockRange[0], rootBundle.bundleEvaluationBlockNumbers[index]];
+      return endBlock > startBlock ? [startBlock, endBlock] : [endBlock, endBlock];
+    });
+
     const mainnetBlockRange = blockRangesImpliedByBundleEndBlocks[0];
     const mainnetBundleStartBlock = mainnetBlockRange[0];
     const chainIds = this.clients.configStoreClient.getChainIdIndicesForBlock(mainnetBundleStartBlock);