gloas beacon_block gossip rules

[mehdi-aouadi]

PR Description

This PR refactors the monolithic BlockGossipValidator into a more flexible, maintainable, and testable two-stage pipeline architecture. The new design addresses the challenges of adding fork-specific validation logic and improves the clarity of the validation process.

1. Introduced a Two-Stage Pipeline:
   Stateless Pipeline: Executes fast, preliminary checks (e.g., slot checks, parent known, equivocation peek) without needing the parent state.
   Stateful Pipeline: Executes slower, state-dependent checks (e.g., signature verification, proposer index) only if the stateless checks pass.
2. Modular Validation Rules:
   Each validation check is now a small, single-responsibility class implementing either StatelessValidationRule or StatefulValidationRule depending on if it needs a parent state access or not.
   The new ForkValidationPipelines class composes these rules into ordered lists for each consensus fork, making fork-specific logic explicit and easy to manage.

Fixed Issue(s)

#10064

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Refactors block gossip validation into modular, fork-aware stateless/stateful pipelines with a separate equivocation checker, updating integrations and tests accordingly.

• Validation:
  • Introduces StatefulValidationRule and StatelessValidationRule interfaces and per-fork rule sets via BlockGossipValidationPipelines.
  • Replaces monolithic validation.BlockGossipValidator with validation.block.BlockGossipValidator that executes stateless then stateful pipelines.
  • Adds EquivocationChecker and SlotAndProposerIndex; removes old inline equivocation tracking.
  • Implements fork-specific rules: Phase0/Altair (FutureSlotRule, BlockParent*, ExpectedProposerRule, ProposerSignatureRule, etc.), Bellatrix (ExecutionPayloadTimestampRule), Deneb (KzgCommitmentsRule), and Gloas (ExecutionPayloadParent*Rule).
• Integrations:
  • Updates BeaconChainController and SyncingNodeManager to build BlockGossipValidator with EquivocationChecker.
  • Updates BlockBroadcastValidator/Impl to reference new validation.block classes and EquivocationChecker results.
• Tests:
  • Adjusts tests to new packages/APIs and enum paths; maintains behavior coverage for gossip, consensus, and equivocation checks.

^{Written by Cursor Bugbot for commit d32db74. This will update automatically on new commits. Configure here.}

[StefanBratanov]

I don't mind this approach actually, I am questioning a bit every rule as a separate class, can probably group some of those who may never change into one and then having more fork specific separately.

[mehdi-aouadi]

I don't mind this approach actually, I am questioning a bit every rule as a separate class, can probably group some of those who may never change into one and then having more fork specific separately.

We definitely can group some rules under a single class (at least those that are always applied for all forks or those checking the same data like the slot related ones...) and we could also make the rules interfaces functional and implement the checks in lambdas (less files but less testable too).
My main goal is to make it easy to compare the spec to the implementation and get rid of all the fork related logic by having completely separate pipelines

[StefanBratanov]

I don't mind this approach actually, I am questioning a bit every rule as a separate class, can probably group some of those who may never change into one and then having more fork specific separately.

We definitely can group some rules under a single class (at least those that are always applied for all forks or those checking the same data like the slot related ones...) and we could also make the rules interfaces functional and implement the checks in lambdas (less files but less testable too). My main goal is to make it easy to compare the spec to the implementation and get rif of all the fork related logic by having completely separate pipelines

I like the approach, the operations are O(1) and is easier to see what is happening.

[mehdi-aouadi]

Closing in favour of #10140