feat: stmgr: add env to disable premigrations

[travisperson]

Setting the environment variable LOTUS_DISABLE_PRE_MIGRATIONS=1 will discard premigrations for all upgrade.

Related Issues

#10048

Proposed Changes

• Add environment variable LOTUS_DISABLE_PRE_MIGRATIONS which when set to 1 stops pre-migrations from being executed.
• Migrations are still scheduled and part of the statement managers' migration table.

Additional Info

Checklist

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

• Commits have a clear commit message.
• 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, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[travisperson]

My original thought was to just set the PreMigration array for each migration to empty during the construction of the state manager when this environment var is set. This would lead to nothing getting scheduled.

If we had a way to print the current schedule / next scheduled task I think this would still be the correct way to go. However, I don't believe we have that functionality. So instead I'm opting to just exit pre-migrations early.

This will ensure that a log message is created around the time the pre-migration was supposed to run stating that it was skipped. I think this will make debugging things a bit easier

[arajasek]

I think this is a pretty good way to go about it, honestly.

[travisperson]

Is there any documentation in this lotus here that also should be updated as part of this PR? Otherwise I think the migration documentation I want to write will be the location of this new environment variable.

[arajasek]

LGTM, thank you!

This would be relatively easy to test -- we can spin up custom upgrade schedules in itests (eg.

lotus/itests/migration_nv18_test.go

Line 42 in cdf3812

Migration: filcns.UpgradeActorsV10,

). I think we could have a test that simply panics on pre-migration, and succeeds on the actual migration -- we succeed if we get to the next network version.

I don't think it's critical to have this test, but worth doing.

[arajasek]

I think this is a pretty good way to go about it, honestly.