Respect checkpoint size constraints

[raulk]

The maximum size of checkpoints is limited by several environmental and practical constraints:

• Payload limits for transactions submittable to parents (e.g. Filecoin defines a max payload size of ? -- can't remember -- need to dig in).
• (Today) Block gas limit on the parent, which limits the amount of eager execution we can perform through xnet messaging.
• more?

Currently it is possible to queue messages which, when aggregated into a bundle, end up exceeding the above constraints upon submission within a checkpoint.

Furthermore, as checkpoints grow to include more data within them (e.g. more summaries in activity rollups) this problem is aggravated.

We should consider improving our local checkpoint validation and flushing logic to make it more intelligent, so that:

1. We never accept single xnet messages that would, in themselves, exceed the parent's tx payload limt.
2. We flush an early checkpoint when we add a message that would cause an overflow.
3. We reserve N bytes in checkpoints to carry other data, e.g. activity rollups. In most cases these will have to be worst case scenario estimations.
4. etc.

[cryptoAtwill]

Regarding the size constraint, I think bottom up cross network message can be part of roll up as well. Only the commitment is needed to be submitted in the bottom up checkpoint. The commitment is just the root of merkle tree over Vec<IPCEnvelop>, and attached as part of the roll up. Then in relayer or anyone, can drive the execution by providing the merkle proof and original IPCEnvelop. The gateway contract can ensure the bottom up nonce is the expected nonce in IPCEnvelop. Practically there is no diff in current mechanism.