Block import pipeline refactor

[cchudant]

Pull Request type

• Refactor

Does this introduce a breaking change?

Yes: block number in db in class info is stored differently

Other information

This is a refactor I've been working on a little bit. I don't expect this to reach a point where it's merge-able soon as it's not a top priority

• Decouple block fetching from block importing, the plan is to phase out dc-sync entirely and replace it with just the fetching from FGW code.
• Ability to pick and choose what you trust vs validate
• Built-in polling mode
• Simplify the pipeline: fetching and pre_validate (formerly named convert) is now done in the same task, as it didn't need to be split into two workers. update trie and db store are similarly also merged into a single task too. This allows us to only have the driving logic of the pipeline in a single place.

The pipeline is designed to fit with p2p retry/scoring and reorgs when we want to implement them: the driving of the pipeline being now in a single place, we can handle flushing the pipeline and retry logic there.

Current pipeline architecture docs is https://github.com/madara-alliance/madara/blob/main/crates/client/sync/src/l2.rs#L324 New pipeline architecture docs is https://github.com/madara-alliance/madara/blob/block_import/crates/client/block_import/src/lib.rs#L1

[cchudant]

Closing in favor of #232. The pipeline part of this PR will be implemented before p2p :)