EVM Node: Support signing and applying blueprints concurrently

Close L2-151

What

This patch refactors the blueprint application logic within the EVM node. Since we now longer forward signed blueprint chunks to the kernel, it becomes possible to concurrently sign and apply a given blueprint. That is, the signing and payload creation now happen in parallel to the state transition.

Why

The previous implementation required the blueprint to be fully prepared and signed before it could be applied to the EVM state. This created a bottleneck, as state application had to wait for cryptographic operations to complete. By passing the unsigned chunks directly to the application function, the EVM state transition can begin immediately, while the signing process runs concurrently. This change is intended to reduce block production latency, especially in setups where keys are held by a KMS.

How

The Evm_context.apply_blueprint function has now a new apply_chunks companion function. This function takes a list of unsigned_chunk and a signer. Internally, the Evm_context ensures the applying and signing of the chunks are done concurrently. The block producer is updated to call this function.

The Apply_blueprint worker request has been updated to carry the unsigned chunks separately from the payload promise. Consequently, the signature verification logic within apply_blueprint_store_unsafe has been moved, as the function now receives trusted, unsigned chunks. The signature check is now done in the Evm_context.apply_blueprint top-level function (outside of the worker)

Besides, both apply_blueprint and apply_chunks now preemptively check that the sequencer behind the submitted blueprint is the expected one. The former is checking the signature using its current state, while the latter trusts the sequencer declared by its caller (the block producer). In both cases, the case where a sequencer upgrade is pending is taken into account.

For apply_chunks to work, the Patch_state worker request has been updated to propagate its changes to the head_info global reference. Otherwise, the first block created by the sandbox on a non-empty state would be refused due to a mismatch in sequencer identity (as the head_info reference would still contain the EVM state initialized at load time, prior to the sequencer overwrite).

Finally, the new workflow required some clean-up. The blueprint_proposal event has been removed as it no longer corresponds to a distinct step in the production flow. The smart_rollup_address field of the Block_producer worker is dropped because the Evm_context worker is now the component producing the blueprint payloads.

Manually testing the MR

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR