Fixes#1266
Issue #1266 was triggered when the recorded block number exceeded the reported
max block number as can happen temporary when the node that gives the latest
block number is farther behind than the node that gave the block data.
The previous `Explorer.Chain.missing_block_number_ranges` query added in
#1230 did not account for the max block number in the database
exceeding the range max. When this occurs, an errant range was produced
by the #1230 query because it chose the greatest of the range and the
max block when trying to find the end point for the gap search.
The testing did not catch #1266 because the doctests only used block
numbers that exceeded the search range, by 1 and the bug did not show up
until it was 2 or more.
The new query is split into 4 subqueries:
1. missing prefix when range min < min(block.number)
2. missing infix when the blocks aren't in the range at all
3. missing suffix when max(block.number) < range max
4. gaps between existent block numbers
This version is also more efficient as there is only a single sort of
the outer `UNION ALL` result instead of a sort of real blocks and fake
end points for the range. It is able to move the `UNION ALL` up because
it doesn't need to produce fake end cap blocks. This positioning of the
`UNION ALL` and `ORDER BY` on the outer most query allows for all 4
queries to use `one_consensus_block_at_height` index and either a limit
(for `min`/`max`) or a window aggregate (for `lag`), which has minimal,
single row cost.