Design a mechanism to reduce the need for two network upgrades for F3 activation to one

[masih]

Background

To activate F3 two network upgrades are required:

1. to allow a period of passive testing to determine the final manifest configuration values, e.g. delta, rebroadcast backoff, lookback etc.
2. making a release with those empirically determined values to then upgrade the network with.

As a two step concept there is no getting away from this from engineering perspective; it is required to measure things and perform experimentation in order to determine network wide constants.

But logistically, the process can be simplified such that those values can be updated without requiring 2 network upgrade: by delegation of control to a party/committee to set those variables at runtime.

Done Criteria

There is a "design document" that outlines how a tightly scoped, easily abortable, and fully transparent mechanism can be built into go-f3 / Lotus to allow for a one-time setting of F3 activation parameters that bypasses the time / coordination cost of a network upgrade.

This document should include:

1. Pseudo code of the smart contract
2. Who would have access to the smart contract
3. List of changes required in Lotus such that F3 parameter values are not required at build time
4. Sequence of events for "releasing" and then using this mechanism (e.g., smart contract published, contract addressed integrated in Lotus RC, mechanism tested in Calibration, etc.)
5. Estimate for the amount of engineering effort to pull this off

Why Important

This is even being considered because of the way it could save the network the time and coordination effort that goes into a network upgrade. Once the design is completed and communicated to the community, the community can still reject it and we fallback to doing a network upgrade.

We need to do this design phase so:

1. Community can accurately assess the idea
2. We can make realistic estimates and then timelines, given this will need to be done in concert with a larger nv25 upgrade train that has other FIPs. (As an extreme, if adding this mechanism took an extra calendar month from an engineering perspective, it would we become clear that it's likely not in scope for a mid-February 2025 nv25).

Notes

1. This issue isn't tracking all the related comms for such an effort.
2. The basic idea is to set up a smart contract that would allow a specific (mutisig) key to set manifest values for the network by some deadline and only once. After they are set, that smart contract would lock itself into an immutable config.

[BigLep]

Thanks for creating this issue @masih. I update the issue description a bit by giving it done criteria that is focused on creating the design. There will be other/followup tasks for communications, implementation, etc.