Tx_rollup: Various scenario to tests

This issue summarizes various scenarios to tests for transactional rollups (only for the protocol side):

Regression

Regressions tests to ensure that if the behavior is changed, it is catched.

Batch

• check the minimum size for a batch
• check a random batch submission
• check the maximum default size for a batch
• check the minimum allowed size for a batch with a new protocol constant parameter
• check client command batch submission with an invalid rollup address

Inbox

• check the maximum default inbox size
• check the maximum default inbox size with a new protocol constant parameter (? - see comments)

Commitment finalization

• Test finalisation with no inbox
• Test finalization with an inbox without commitment
• Test finalization with a pending commitment but the refutation period time is too short
• Test a valid finalization on a pending commitment

RPCs

• check the get_state RPC with the initial state
• check the get_inbox RPC with a non-empty inbox
• check the get_inbox RPC with a level in the future
• check the get_inbox RPC when the inbox was removed
• check the get_commitment RPC with a level containing an RPC
• check the get_commitment RPC with a level in the future
• check the get_commitment RPC with a commitment removed

Scenarios

Batches

• Test an origination with a single batch submission
• Test posting messages in several inboxes
• Test that a batch of message does not depend on the inbox size

Commitments

• Test a valid commitment for a batch
• Test two valid commitments in a row
• Test committing twice on the same batch
• Test a commitment without predecessor while it should

To be validated

• case where an unparsable batch is rejected (that is, is a no-op)
• case where a batch with an ill-signed transaction is rejected (that is, is a no-op)
• case where a batch with an operation having a bad counter is rejected (that is, is a no-op)
• case where:
  • append_message that triggers Inbox_count_would_exceed_limit
  • and the message that doesn't fit in the inbox is a deposit from L1
    • what's the status of the L1 operation?
• what happens if we ask to withdraw and provide a quite big withdraw_index ? (see !4523 (comment 868018313) for more details)
• Test where there is more than one withdraw for a claimer in an inbox:
  • in different batches
  • in the same batch
  • one of them is a failing deposit
  • both are failing deposits
• A test of three deposits of max_int, from the same source/contract (David working on these)
  • to the same destination (fresh or not)
  • to two different destinations (fresh or not)
  • to three different destinations (fresh or not)
• check a rejection where the computation yields a result similar to what's on-chain (? - see comments)
• test rejections with various errors in the apply function (parsing, invalid counter, ...)
• rejection tests where some commitments are orphan (same manager as rejected commitment or not) + try to withdraw funds
• max number of withdraws per batch: test the following case: (<- WIP)
  • the L1 node + an honest rollup node use a limit L of withdraws per batch
  • a malicious rollup node sends a batch that generates more than L withdraws and sends a commitment that certifies that this batch is correct
  • a rejection operation (sent for instance by the honest rollup node) should allow to reject the batch when evaluated on L1, because evaluating the batch should fail (with Maximum_withdraws_per_message_exceeded).
• add a test where the proof's size is above the limit
• bonds tests: https://hackmd.io/dozd_9L_Qz63C2elXurmyw?both
• state tests: reject a commitment whose predecessor has been removed from storage
• add tests where positions are negative ?