refactor block gossip validator

[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.

This PR is still in progress. The new block gossip validator is not used yet. It could be extended to other gossip topics and replace the existing gossip validators.

Fixed Issue(s)

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.

[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.