[Enhancement] UX friendly output of ProveCommit stagger feature and default

[rjan90]

Checklist

• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated feature request to propose.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

With #10543 we now have the ability to stagger ProveCommits if the BaseFee is under the AggregateAboveBaseFee threshold at the time of publishing the messages. It will stagger XX amount of ProveCommits per epoch depending on the config.

Two follow up items that would be nice:

1. Set a sensible default config for MaxSectorProveCommitsSubmittedPerEpoch which prevents any SySErrorOutOfGas issues, and that will not span too many epochs to send all the ProveCommits if there is a large pool of sectors currently waiting in the commit batch queue.

• Set default for MaxSectorProveCommitsSubmittedPerEpoch #10728

2. A friendly UX when these messages gets sent out. Currently the CLI will wait for all the messages in SectorCommitFlush to finish before it prints it in the CLI, which can lead users to think that something is broken.

Current behavior:
Manually push the batch, and the CLI just waits here:

root@Ubuntu-2004-focal-amd64-base ~ # lotus-miner sectors batching commit --publish-now

And depending on how many epochs those ProveCommit messages are spread over, that wait time can take a bit of time. When SectorCommitFlush finally finishes, it prints all the sectors and their MsgCID:

lotus-miner sectors batching commit --publish-now
Batch 0:
        Message: bafy2bzacebezq3elxep4ebdujl45lhqp5m6chzwa744m7xs27rmqqnovd43y2
        Sectors:
                180     OK
Batch 1:
        Message: bafy2bzaceamwiu6sapvncyumpxalqpj33un4zitzvj5sdak4kbynvjrpl7j6i
        Sectors:
                184     OK
Batch 2:
        Message: bafy2bzacea54f6locufcwhmnk6ymmk6urc3h33sulalwiqvcsll3cfzeeq7v4
        Sectors:
                182     OK
Batch 3:
        Message: bafy2bzaceb6iwprzal7ycurbqvqeqsvfespgwvxq3rodbz5h4wsxemw6h4cc4
        Sectors:
                181     OK
Batch 4:
        Message: bafy2bzacedwj5dm54u6fpyikobyytkjq6xqath5npyrdbymbnrtaks45fxwnq
        Sectors:
                185     OK
Batch 5:
        Message: bafy2bzacea2ksypi73ov2ntkufue7csrkmvfozrudgqf4zlup4qflx5o57x2o
        Sectors:
                186     OK
Batch 6:
        Message: bafy2bzacebp42js4qcupw2kx6tnpyxwypmovopcogry4yw5nmpzicwytngphu
        Sectors:
                183     OK

Describe the solution you'd like

Wanted behavior:

Ideally we would notify the user that it has processed XX amount of ProveCommit messages and what XX amount of ProveCommit messages are waiting to be staggered. So a potential CLI output could look something like this:

lotus-miner sectors batching commit --publish-now
2 ProveCommitSector messages sent in epoch 1234506:

Batch 0:
        Message: bafy2bzacebezq3elxep4ebdujl45lhqp5m6chzwa744m7xs27rmqqnovd43y2
        Sectors:
                180     OK
Batch 1:
        Message: bafy2bzaceamwiu6sapvncyumpxalqpj33un4zitzvj5sdak4kbynvjrpl7j6i
        Sectors:
                184     OK
There are 6 remaining ProveCommit messages to be flushed.

2 ProveCommitSector messages sent in epoch 1234507:

Batch 3:
        Message: bafy2bzaceb6iwprzal7ycurbqvqeqsvfespgwvxq3rodbz5h4wsxemw6h4cc4
        Sectors:
                181     OK
Batch 4:
        Message: bafy2bzacedwj5dm54u6fpyikobyytkjq6xqath5npyrdbymbnrtaks45fxwnq
        Sectors:
                185     OK
There are 4 remaining ProveCommit messages to be flushed.   
.........

Describe alternatives you've considered

No response

Additional context

No response

[rjan90]

Got some feedback that the current default that was set in #10728, occasional still fails to prevent the SySErrOutOfGas in certain scenarious. We can probably make the default even lower, but would be good to stage this with the a more UX-friendly output as proposed in 2.