feat: Add Dedicated Local Launcher

[Bisht13]

Description

This PR adds support for custom payload attributes in development mode (--dev)

closes #14064

[Bisht13]

@mattsse is it okay if the user has to implement PayloadAttributesBuilder for their CustomPayloadAttributes like this

impl PayloadAttributesBuilder<CustomPayloadAttributes> for LocalPayloadAttributesBuilder<ChainSpec>
where
    ChainSpec: Send + Sync + EthereumHardforks + 'static,
{
    fn build(&self, timestamp: u64) -> CustomPayloadAttributes {
        CustomPayloadAttributes {
            inner: EthPayloadAttributes {
                timestamp,
                prev_randao: B256::random(),
                suggested_fee_recipient: Address::random(),
                withdrawals: self
                    .chain_spec()
                    .is_shanghai_active_at_timestamp(timestamp)
                    .then(Default::default),
                parent_beacon_block_root: self
                    .chain_spec()
                    .is_cancun_active_at_timestamp(timestamp)
                    .then(B256::random),
            },
            custom: 0,
        }
    }
}

Having difficulty doing if this type implements a trait, do X, otherwise do Y, initially I thought that if a user defines custom payload attributes and tries to run dev mode without implementing the required trait then it should throw a runtime error like custom payload attributes not handled but since trait check happens in compile time, the compilation is failing (even the user doesn't use the dev mode because the entire binary compiles). Let me know if you have a better solution or idea for handling this.

[Bisht13]

Also @mattsse was wondering that something like this can be done to choose the launcher, but again because of rust compilation time both branches are trait checked during compilation and for someone to use CustomPayloadAttributes, they'd need to impl PayloadAttributesBuilder for the corresponding struct even if they don't wish to run the node in dev mode

[mattsse]

is it okay if the user has to implement PayloadAttributesBuilder for their CustomPayloadAttributes like this

yep that would be expected, in case this shouldn't be supported, this can return an error for example

[Bisht13]

So I think one way to approach this problem is via specialization, 2 things to note with that,

• First solution: we can use #![feature(specialization)] which is an incomplete feature right now but is the most straightforward implementation.
• Second solution: move the PayloadAttributesBuilder implementation for LocalPayloadAttributesBuilder in reth-ethereum-forks crate and use #![feature(min_specialization)] instead (which is recommended over specialization right now) and remove the Clone trait bound (assuming this is not getting used anywhere) from EthereumHardfork trait. This requires a not so ideal refactor, keeping payload code in reth-ethereum-forks crate.

I, personally, think the first solution is a better one and the current PR reflects that but would love to hear your thoughts! @mattsse

[Bisht13]

I have implemented a dedicated dev/local launcher which gets used if the node is run in dev mode, also added PayloadAttributesBuilderAddOn for providing PayloadAttributesBuilder for local launcher on demand. The impl for LocalEngineNodeLauncher is similar to EngineNodeLauncher leading to a lot of DRY code, this is intended as someone might want to tweak few things in one engine but not in another.

PS dropped specialization since it's not stable