Improve Lotus Tooling for Managing Sector Extension & Snap-Deals Following FIP-0045

[TippyFlitsUK]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

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

Lotus Version

All versions

Repro Steps

1. Extend sectors for new snap deals
2. Snap deal fails due to term end beyond sector expiration message

Describe the Bug

The recent datacap redesign that landed with FIP-0045 has also introduced new criteria for upgraded CC sectors that have been made Available for the onboarding of verified datacap deals through snapping.

An upgraded and Available CC sector must now have a duration that is no longer than 90 days in excess of the verified deal term that is being stored in said sector.

Sector extension for snap deals is already an onerous SP task that causes much confusion and this additional requirement will undoubtedly lead to further difficulties for SPs who are onboarding verified deals.

Most SPs currently extend large batches of sectors to the maximum term available to save costs. Extending sectors individually depending on the deal term would be prohibitively expensive.

A brief discussion in this Slack thread with @magik6k and the FILCollins server team highlighted some ways in which this process could be greatly improved with enhanced Lotus tooling such as visualization of distributed sector expirations and better data-to-sector allocation in Lotus.

Ideas and comments from the Lotus Team and SP community would be much appreciated!!

Logging Information

N/A

[LexLuthr]

We also need to take into account the work it will take to ensure a fair distribution of sector expiration epoch to accommodate different deal durations. This would also affect the amount of extend messages we send as we can't extend all sectors or even a large number of sectors at once. Which is turn would affect the cost of operating a miner (likely to go up).
It would be ideal to solve this within the code (or Protocol) rather than putting it on the users to try to resolve using scripts. based on visualisation. There are already too many automations SPs have built for snapping sectors.
As a user, I would consider it as serious regression in user experience.