Tx_rollup,Node: switch to apply to prover-apply

Context

First steps of having proofs, commitments and rejections in the rollup-node. We switch from the classic context and apply to the prover context and prover apply.

Inboxes interpretation

Now, interpretation of inboxes produces proofs. When the proof is larger than the protocol limit, we replace the whatever result there is by a dedicated error and we drop the modified context.

Batch

Now, the batcher takes transactions one by one from the queue until either, and produces at most 10 batches (the constant did not change)

• The batch is larger than the L1 limit (i.e. 5k bytes)
• The proof is larger tha, the L1 limit (i.e. 30k bytes)

Proof RPC

It exposes an RPC to compute the proof for a given message in a given inbox.

Manually testing the MR

First thing to check is: whether the messages interpretation is broken:

• are the messages correctly applied
• is the context changed (when it should be)

Second thing to test is the actual error when the proofs are too-large, which is not yet tested in this merge request.

Checklist

• n/a Document the interface of any function added or modified (see the coding guidelines)
• n/a Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• n/a 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