trace_decoder: Tweak batch size for small blocks

[Nashtare]

Simply halves the block in two chunks in case the initial batch size is too large, to prevent wasting ressources on dummy payloads.

closes #457

Follow-up work mentioned #518 will improve on this but this requires additional benchmarkings / analysis of how much our instances can optimally handle.

[0xaatif]

There's a bunch of documentation in these issues. Could the knowledge there be transferred to the code?

It would be great to embed what motivates particular operations

[0xaatif]

How urgent is this change?

I'd lean to an approach like this (though I haven't worked out the right approach for padding):

/// Break `txns` into batches of length `hint`, prioritising creating at least two batches.
fn batch(mut txns: Vec<TxnInfo>, hint: NonZero<usize>) -> Vec<Vec<TxnInfo>> {
    let n_batches = txns.iter().chunks(hint.get()).into_iter().count();
    match (txns.len(), n_batches) {
        // enough
        (_, 2..) => txns
            .into_iter()
            .chunks(hint.get())
            .into_iter()
            .map(FromIterator::from_iter)
            .collect(),
        // not enough batches at `hint`, but enough real transactions
        (2.., ..2) => {
            let second = txns.split_off(txns.len() / 2);
            vec![txns, second]
        }
        (0 | 1, _) => todo!("not enough real transactions - pad"),
    }
}

This would slot in well with my planned refactoring of the backend (and simple heuristics that might be forthcoming in #518):

zk_evm/trace_decoder/src/lib.rs

Lines 462 to 472 in e03997d

	let batches = middle::middle(
	state,
	storage,
	txn_info
	.into_iter()
	.chunks(batch_size.get())
	.into_iter()
	.map(FromIterator::from_iter)
	.collect(),
	&mut code,
	)?;

I'm happy to merge this as an interim measure if required - that refactoring is blocked on testing :^)

[Nashtare]

How urgent is this change?

It's not urgent, though it affects IMX benchmarks, as both their test load chain and real chain is having a relatively low number of txn / block, often inducing dummy proofs with the current approach.

I'm happy to merge this as an interim measure if required

Ideally this approach would be replaced by a dynamic batching based on txn state access count and state trie growth, though this requires additional measurements before assigning proper weights to determine the optimal batch sizes, hence this standalone PR.