switch maxBatchNum to maxBlockNum

[krlosMata]

Summary

Use an ethereum block as a timeout instead of a rollup batch

Rationale

User could add a timeout in his transaction by signing the maxNumBatch field. This gives the user the confidence that the transaction cannot be forged if currentNumBatch > maxNumBatch.
This approach implies relying on the batch number in order to setup a timeout. Batch number could be manipulated by the coordinators since they are the ones that could forge batches and thus increase the batch number.
If there is just one only coordinator in the protocol, batch number manipulation is straightforward since no competitors will forge any batches.
If we assume a bunch of coordinators in the protocol, the maxNumBatch field fixes a deadline of _slotDeadline defined in the smart contract, which dteemrines the number of blocks after the beginning of a slot after which any coordinator can forge. Current protocol parameters determines that _slotDeadline = 20 blocks = 5 min. Therefore, timeout guarantees for a user would be set at 5 minutes.
That timeout may not be enough to prevent high price changes when submitting atomic swaps. Then, moving to maxNumBlock would give to user more confidence in terms of timeout.

Drawback

If we took maxBlockNum as a timeout parameter, coordinaotr could not know exactly in which etehreum block the forgeBatch transaction will be inserted. This could lead to wrong proof generation due to high peak demand on ethereum.
A coordinator should perform the following tasks before insert a user transaction in ethereum:

• generate proof
• submit forgeBatch transaction and get mined

Assuming a very well estimation of when the forgeBatch would be mined, at least the coordinator should wait for the proof to be build and one block for his transaction to be mined. Given that current proof generation cost around 1 minute to compute, this would give a user a timeout assurance of 75 seconds.
From user perspective, user would be more confident regarding timeout precision but from coordinator perspective it could led to break the proof computation pipeline and adds complexity at the time to estimate forgeBatch transaction mining. A regular coordinator will not incur in non-profitable proof generation, so coordinator could only accept wide maxBlockNum timeouts just to not break its pipeline. That leads to not have any gain in terms of timeout accuracy if we change from maxNumBatch to maxBlockNum

[krlosMata]

Any new idea is welcome in order to reduce timeout user confidence xD