feat: limit PoSted partitions to 3

[arajasek]

There's concern that certain PoSt operations can be so expensive that they don't fit in a single block at all (currently 10B gas). This is especially concerning if PoSts cannot be disputed.

This PR adds a new dedicated limit for the number of partitions that can be proven in a single PoSt message, and sets it to 2. This limit thus ensures that "bad" proofs can be safely disputed, as they will only ever cover 2 partitions at a time.

I'm proposing adding a new dedicated limit, instead of modifying either ADDRESSED_SECTORS_MAX or ADDRESSED_PARTITIONS_MAX, since those values are used elsewhere. I'd like this change to be very targeted at PoSt messages only.

[arajasek]

We'll need to advertise this change loudly so that mining software can adjust to deal with it.

[Stebalien]

The only possible concern is that this might cause some issues with butterfly/dev networks (i.e., lots of small window posts because partitions are small) but, IMO, this is the right short-term fix.

The right long-term fix is to remove 99% of these limits because they were originally introduced pre-wasm to limit memory/compute.

[codecov-commenter]

Codecov Report

Merging #1436 (0840c26) into master (b81da94) will decrease coverage by 0.06%.
Report is 1 commits behind head on master.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1436      +/-   ##
==========================================
- Coverage   91.09%   91.03%   -0.06%     
==========================================
  Files         145      145              
  Lines       27862    27867       +5     
==========================================
- Hits        25381    25369      -12     
- Misses       2481     2498      +17     

Files	Coverage Δ
actors/miner/src/lib.rs	84.86% <100.00%> (+0.01%)	⬆️
runtime/src/runtime/policy.rs	98.46% <100.00%> (+0.01%)	⬆️

... and 3 files with indirect coverage changes

[anorth]

The structure of this change seems fine, but 2 seems like a very low limit that I'm not aware of a good justification for.

[zhiqiangxu]

Worth mentioning that at venus, the largest partitions in a batch is currently 3.

[arajasek]

@anorth @zhiqiangxu Thanks for the feedback! I'm going to increase this to 3.

[beck-8]

Is it too hasty to directly change 10 to 3 on the consensus side?

[Fatman13]

Shouldn't this be FIPed?
What would be the required security level for an issue to warrant its bypassing of FIP process?
What is the security level of this issue?
Any analysis on how this would impact current wdPost gas dynamics?