MaxCommitBatch/ MaxPreCommitBatch is too high

[jennijuju]

A couple protocol changes have resulted in PCB and PCA gas usage increase:

• FVM M1 introduce proper gas accounting and has resulted in the overall gas usage,
• FIP 0045 introduced additional claim/allocation operations for deal activation during PCB/PCA which increase the gas usage

That being said, if user creates messages with the previous MaxPreCommitBatch (256) and MaxCommitBatch (819) - the message likely will fail due to message execution failed: exit SysErrOutOfGas as the block limit has reached.

its similar with #8986 #8982, however, again with higher impact from fip0045

we should

• perform gas benchmarking and adjust the max values (this is set in protocol, we likely should adjust accordingly there as its protocol-impossible to include this many sectors in one message under the current block limit)
• can start with lower max fees in lotus for now

[arajasek]

Yes, I think it's time we do this. In addition to "making more sense", I think it's a good idea to have fewer messages taking up (potentially) an entire gas block limit. I think as protocol designers we want such messages to be rare (though they'll always be possible with the FEVM).

[arajasek]

Would suggest creating a separate actors issue for the first point.

[shrenujbansal]

Its difficult to reliably get a sensible upper bound for what each of these limits needs to be since gas fees for these messages depends not only on the messages themselves but on the actor state as well, leading to a high variance in the number of sectors that can be aggregated per message
This is the case, even if you split messages for verified and non-verified sectors

My proposal is to simulate PCA/PCB with a StateCall and if we see that the message requires more gas than the block limit, split the batch into 2 and try again continuously until we arrive at a batch size that works

For ProveCommitAggregate, this means calculating the aggregate proofs multiple times. Talking to @magik6k, this should be cheap enough to do