feat: wdpost: Config for maximum partition count per message

[magik6k]

Related Issues

Some users see windowPoSt messages exceed block gas limit.

Proposed Changes

Add a new config value which allows limiting the number of partitions per deadline to values lower that the network limit

[Proving]
  # Maximum number of partitions to prove in a single SubmitWindowPoSt messace. 0 = network limit (10 in nv16)
  # 
  # A single partition may contain up to 2349 32GiB sectors, or 2300 64GiB sectors.
  # 
  # The maximum number of sectors which can be proven in a single PoSt message is 25000 in network version 16, which
  # means that a single message can prove at most 10 partinions
  # 
  # In some cases when submitting PoSt messages which are recovering sectors, the default network limit may still be
  # too high to fit in the block gas limit; In those cases it may be necesary to set this value to something lower
  # than 10; Note that setting this value lower may result in less efficient gas use - more messages will be sent,
  # to prove each deadline, resulting in more total gas use (but each message will have lower gas limit)
  # 
  # Setting this value above the network limit has no effect
  #
  # type: int
  # env var: LOTUS_PROVING_MAXPARTITIONSPERMESSAGE
  #MaxPartitionsPerMessage = 0

I don't have good data to suggest safe values, but this gas use in a few random messages which landed recently on mainnet:
1 partition with 1.1B limit
2 partitions with 2.1B limit
2 partitions with 2.9B limit
2 partitions with 4.1B limit
5 partitions with 8.1B limit
3 partitions with 5.3B limit

This would suggest that:

• 1 partition per message is as conservative as one can get
• 2/3 are most likely safe in all cases (more data needed though)
• 4+ depend on the miner actor (may or may not be safe, more data needed)

Checklist

Before you mark the PR ready for review, please make sure that:

• All commits have a clear commit message.
• The PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, INTERFACE BREAKING CHANGE, CONSENSUS BREAKING, build, chore, ci, docs,perf, refactor, revert, style, test
  • area: api, chain, state, vm, data transfer, market, mempool, message, block production, multisig, networking, paychan, proving, sealing, wallet, deps
• This PR has tests for new functionality or change in behaviour
• If new user-facing features are introduced, clear usage guidelines and / or documentation updates should be included in https://lotus.filecoin.io or Discussion Tutorials.
• CI is green