Security: Handle gossiped blocks that are a long way ahead of the current tip

[teor2345]

Is your feature request related to a problem? Please describe.

In #1328, Zebra downloads and verifies blocks gossiped via AdvertiseBlock requests.

But these blocks can be a long way ahead of the local chain tip. If they are, they wait on:

• their range being added to the checkpoint queue,
• their parent being added to the non-finalized state queue, or
• their UTXO requests from the block verifier (consensus: add timeout to UTXO queries #1391).

Keeping these blocks around might fill up memory with blocks and tasks that won't complete for a long time.

These issues can also happen if peers send incorrect ObtainTips or ExtendTips responses to the syncer, but that's much less likely - and it should be handled by sync restarts.

Describe the alternatives you've considered

There are a number of different solutions to this issue:

• if a downloaded block is more than the lookahead limit (configurable) ahead of the current non-finalized tip, drop it
  • limits the size of the non-finalised queue, preventing memory denial of service
• if the checkpoint queue grows too large, drop a checkpoint's worth (400) of the highest blocks
• put a timeout on UTXO requests (consensus: add timeout to UTXO queries #1391)
• put a timeout on block download and verification requests (Add sync and inbound timeouts #1586)

We'll need a solution for each different kind of queue.

Additional context

This change isn't a priority unless we actually see memory usage issues in practice.

But it's a DoS risk, so we might want to fix it before the first stable release.

[hdevalence]

I believe we'll get the behavior we want as a side effect of other work we have to do (#1390).

[teor2345]

I believe we'll get the behavior we want as a side effect of other work we have to do (#1390).

I think #1390 addresses the UTXO case, but not the other internal queues.

See my detailed response in #1391 (comment)