fix: #7869 sealing: Add more deal expiration checks during PRU pipeline

[jennijuju]

Related Issues

resolves #7869

Proposed Changes

add more deal error handling during PRU pipeline so that we can fail early without wasting too much work

Additional Info

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>: <#issue number> <area>: <change being made>
  • example: fix: #1234 mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, INTERFACE BREAKING CHANGE, CONSENSUS BREAKING, build, chore, ci, docs, misc,perf, refactor, revert, style, test
  • area: api, chain, state, vm, data transfer, market, mempool, message, block production, multisig, networking, paychan, proving, sealing, wallet
• 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

[arajasek]

1. i don't know how long ProveReplicaUpdate1 takes, but it may be rerunning the check before calling ProveReplicaUpdate2?
2. what we really want is probably to extend SectorInfo to have a deadline epoch set to its latest deal activation (can be updated along the way as precommit and so on happens). then, every state transition can check if the sector is doomed before investing any more time in it.

but that is outside the scope of this pr -- an issue would be nice to have, though.

[arajasek]

I don't think this is sufficiently different or faster than checkPieces to warrant its own method?

[jennijuju]

1. i don't know how long ProveReplicaUpdate1 takes, but it may be rerunning the check before calling ProveReplicaUpdate2?

PRU1 computes the vanilia proofs so yah it should take a while, added another check before the PRU2 - so it doesnt take much time

[jennijuju]

tho i do think it makes sense to check before PRU2 instead of PRU1 - updated

[jennijuju]

2. what we really want is probably to extend SectorInfo to have a deadline epoch set to its latest deal activation (can be updated along the way as precommit and so on happens). then, every state transition can check if the sector is doomed before investing any more time in it.

i understand what you are proposing wrt the adding to sector info, but the earliest deal start epoch should stay the same after the snap deal sector is packed, so it wont be updated once set? so i guess we can find that in checkPiece, assign to sector info, then check against it?