feat: ChainSpec associated type

[klkvr]

First step for #10272

Adds ChainSpec trait and assoc type to ChainSpecProvider and NodeTypes, for now most of the logic is hardcoded to use the default ChainSpec

[emhane]

nice, setting the AT to a concrete type makes it possible to impl this in incremental prs.

[mattsse]

this is great and allows us to gradually add support for chainspec trait across more components

[emhane]

what's your argument for finding it appropriate to put ChainSpec here? I'd argue it's more appropriate as AT in FullNodeTypes trait, because looking at the other ATs contained in both traits NodeTypes and FullNodeTypes, ChainSpec semantically fits better into FullNodeTypes - the chain spec is more about initialisation of the chain, like db and provider, rather than compilation of the reth program for a specific network, like primitives and engine types.

[klkvr]

I don't have strong opinion here, so would be happy to move it. My understanding was that FullNodeTypes keeps stateful components which are expected to change their behavior during node operation, while NodeTypes configures underlying types/configs for those components

[emhane]

is the chain spec stateless? what about hardforks?

[klkvr]

is the chain spec stateless? what about hardforks?

It can't change on its own during node operation (thus allowing us to keep it in an Arc everywhere). Primitive types can also change between hardforks

[emhane]

pending @mattsse or @joshieDo

[mattsse]

this is great!

this is exactly what we're looking for,

I think we can merge this as is, so more incremental work is unlocked.

cc @joshieDo I want to find a way to integrate this together with your generic type work, I think we should actually try to make NodeType the generic that we pass to everything

smol conflict @klkvr

[mattsse]

this is great and allows us to gradually add support for chainspec trait across more components