feat: sync: validate (early) that blocks fall within range

[Stebalien]

Proposed Changes

This will reject blocks in pubsub validation if they're either:

1. Too far into the future (5 blocks beyond the expected head).
2. Too far into the past (before finality).

Specifically:

1. We were previously rejecting future blocks in the sync logic, but not in pubsub itself.
2. We never used to check if a block was too old.

Motivation: Blocks that are too new/too old can cause us to perform quite a bit of unnecessary work.

We should carefully consider that second check as we may need to tweak it (e.g., to handle network issues?). We may want to base this check on the latest synced head, not the expected epoch.

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• Tests exist for new functionality or change in behavior
• CI is green

[Stebalien]

Well, this definitely broke something.

[Stebalien]

We should carefully consider that second check as we may need to tweak it (e.g., to handle network issues?). We may want to base this check on the latest synced head, not the expected epoch.

Ok, I needed this, but I'm concerned I'm misunderstanding something here. As far as I know, the "catch up" code path shouldn't end up calling IsEpochInConsensusRange.

[ZenGround0]

I don't know this part of the system well enough to be a very useful approver but the idea and implementation seem good.

[magik6k]

Not entirely sure about Ignore/Reject, I guess if we want to be conservative, ignore is better, but I don't have a strong opinion.

Other parts LGTM.

[vyzo]

I think it is better to be conservative and Ignore here, otherwise it might have adverse effects with the score penalties.

Basically we should only do Reject for obviously bad behaviours, not things that can happen naturally.

[Stebalien]

Ok, this should be good to go. It ignores blocks before finality with respect to our current head and 5 blocks after the expected head.