Allow block processing to continue with failed rollups

[badgersrus]

Why this change is needed

https://github.com/ten-protocol/ten-internal/issues/4522

What changes were made as part of this PR

• Add new ErrCriticalRollupProcessing error type that we wrap if we fail the rollup processing after we've verified the rollup was signed by the enclave
• The only reasons we reject block processing now is if the block is already stored, if its ancestor can't be found or if we encounter an error on a rollup signed by the enclave key

PR checks pre-merging

Please indicate below by ticking the checkbox that you have read and performed the required
PR checks

• PR checks reviewed and performed

[tudor-malene]

This is on the right track, but it's quite hard to reason about because of the "block-centric" approach.

Currently (in ingestL1Block) we do:

1. GetRollups - which does all sorts of stuff, from decoding, verifying to verifying signatures.
2. Store Block
3. Process Rollups - the execution and storage

It's hard to reason about errors.

What if we did the following:

1. Store Block
2. For every l1 event of type: common.RollupTx call ProcessRollup, which will do the usual:
   a. Check sequencer signature - we can do this first because the hash in in the header
   b. extract the blob
   c. decode
   d. verify the hashes
   e. ReconstructRollup
   f. pass it to the compression service to Process the rollup

[badgersrus]

@tudor-malene just FYI the processing order above won't work as we need the blob hashes to create the composite hash (its not in the header) so a) will need to come after d) but this will still be easier to follow in this flow.

[badgersrus]

closing to use a fresh branch as the rebase has a nightmare