add devmode launcher implementation

[mattsse]

with the new orchestrator trait design, we can now implement a proper devmode orchestrator directly on top of the auto-seal-consensus implementation and we no longer need to mimic the engine API internally:

reth/crates/consensus/auto-seal/src/task.rs

Lines 159 to 163 in eda161a

	let _ = to_engine.send(BeaconEngineMessage::ForkchoiceUpdated {
	state,
	payload_attrs: None,
	tx,
	});

TODO

• Add DevOrchestrator implementation that drives the MiningTask and advances the node
  

  reth/crates/consensus/auto-seal/src/task.rs

  Lines 83 to 89 in eda161a

  	impl<Executor, Client, Pool, Engine> Future for MiningTask<Client, Pool, Executor, Engine>
  	where
  	Client: StateProviderFactory + CanonChainTracker + Clone + Unpin + 'static,
  	Pool: TransactionPool + Unpin + 'static,
  	Engine: EngineTypes,
  	Executor: BlockExecutorProvider,
  	{

• This should start as a duplicated implementation of MiningTask that emits new ExecutedBlock
• the DevOrchestrator then uses that block to advance the chain by persisting the block, similar to

reth/crates/engine/tree/src/tree/mod.rs

Lines 541 to 544 in eda161a

	/// Run the engine API handler.
	///
	/// This will block the current thread and process incoming messages.
	pub fn run(mut self) {

see for reference:

reth/crates/ethereum/node/src/launch.rs

Line 259 in eda161a

ctx.task_executor().spawn_critical_blocking("consensus engine", async move {

[malik672]

@mattsse assign me

[mattsse]

@malik672 do you still have the capacity to work on this?
happy to provide more pointers if required

[malik672]

@mattsse yes I do, was already working on it but stopped, it's kinda hard ngl

[mattsse]

hehe it is

please open a draft pr and I can provide more directions

[mattsse]

completed