feat(node/engine): refactor engine tasks. fix sequencer startup logic

[theochap]

Description

This PR refactors the core logic of the engine task handler. In particular, it moves duplicate code from the build and the insert unsafe tasks to the forkchoice task.

Changes:

• Add an associated Output type for the EngineTaskExt trait which allows the implementors of this trait to be composed. In particular, the ForkchoiceTask may returns the payload id that was inserted in the EL, which can be used by the BuildTask to consolidate the payload into the engine state.
• Allows the ForkchoiceTask to directly insert newly built payload attributes into the EL (by adding an Option<OpAttributeWithParent> argument to the ForkchoiceTask). This allows to refactors both calls to the FCU inside the BuildTask using the ForkchoiceTask and avoids manually handling the forkchoice updates
• Moves the PayloadStatus verification logic to the ForkchoiceTask to avoid having to perform the same logic in both the BuildTask and the InsertUnsafeTask, which allows to fix the sequencer kickstart issue described in feat(node/service): Sequencer startup routine #2372

Close #2372

Potential follow-ups

• Remove the clones inside the engine tasks
• Refactor the new_payload logic into an engine task to remove duplicate code in the InsertUnsafe and BuildTasks

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 17 lines in your changes missing coverage. Please review.

Project coverage is 82.2%. Comparing base (f7e2933) to head (fb9a5c8).
Report is 1 commits behind head on main.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/node/rpc/src/ws.rs	0.0%	9 Missing ⚠️
crates/node/rpc/src/rollup.rs	0.0%	5 Missing ⚠️
crates/protocol/protocol/src/block.rs	0.0%	3 Missing ⚠️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[clabby]

I think we're packing a bit too much into the ForkchoiceTask here; It now has two responsibilities:

1. Begin a block building job
2. Synchronize the rollup node's view of the forkchoice with the EL

each of which have slight semantic differences in the error handling, response validation checks, etc.

Though I am a fan of the attempt to modularize here. What do you think about separating the concerns here, and renaming ForkchoiceTask (as-is) to SynchronizeTask, and then creating a new task for kicking off block building?

[theochap]

I have reworked this PR a little bit to simplify the data flow/updates for the engine state. Now:

• The engine state only gets updated inside the forkchoice update method. This ensures that we don't have inconsistent state views between the EL and the CL. This simplifies caller methods and improves code reusability.
• The FCU methods take as an input a EngineSyncStateUpdate struct that specifies how to update the engine sync state. This is basically a EngineSyncState with every field being an option. If one wants to update a field of the EngineState, they'll have to set the relevant EngineSyncStateUpdate field to Some(updated_value), which will ensure that the update will get both sent to a FCU and (if successful) updated inside the EngineState