TRCL-2801 To avoid having a node with slow latency (thus +1 on height) being the preferred node

[johnqh]

Imagine two nodes.
Node 1 returns quickly with height.
Node 2 is slow and takes a while to return height + 1.

Previous logic would pick Node 2.

Changed it so both maxHeight and maxHeight + 1 are filtered. This should be fine because if an indexer is halted, it would lag way more than 1 block

[linear]

TRCL-2801 Improve logic for choosing fastest validator by allowing for block height to be within 1 of highest value returned

https://dydx-team.slack.com/archives/C050EGGP57X/p1695923222139669?thread_ts=1695921391.023729&cid=C050EGGP57X

Current validator logic will often return an sub-optimal node:

Imagine a scenario in which you ping a close node and a far node (both increment to new block height at the same time). The further node will more often return the higher block number as it doesn’t receive the request until later than the close node.
The current logic will in general return you the node with the higher latency!

Adjust algorithm to allow for latest block height - 1 to account for scenario above. Also cap the request to timeout at 1.5 seconds.