Release coordination with FVM and built-in actors

[anorth]

This issue is an attempt to document a release process in coordination with the FVM and built-in actors. I expect this post to be updated in place with a process description as we converge on it in comments.

{Insert process here}

[anorth]

@Stebalien suggested a few things in Slack:

1. When the builtin-actors enter "code freeze" for an upgrade, we need to:
   a. Create a release branch in https://github.com/helix-onchain/filecoin.
   b. Cut releases.
   c. Update the helix libraries in the builtin actors.
2. More people need merge access (at the very least, aayush needs merge access).
3. The builtin-actors should always be using the latest version of these libraries. Otherwise, breaking changes will accumulate.

(3) is interesting. From a simple POV, there should be no reason for built-in actors to upgrade these libraries if they don't want new functionality or APIs. Future new functionality may be actively unwanted, e.g. if we change the state schema (#188) to benefit most clients while the built-in actors don't want to perform the migration (yet). But an upgrade can be forced by the shared FVM libraries upon which both this and the built-in actors depend are upgraded, and the built-in actors want or are forced to take that upgrade. So there are two different things which can orthogonally prompt major version bumps, and clients might want one or the other (or both).

One possible approach to this would be to create release branches (and crate names) based on FVM version. Then each main FVM version line can have its own sequence of releases with associated changes. This would be quite a lot of overhead to maintain though.

The reverse possibility of release branches/crates based on functionality is also possible, but seems wrong.

A "simple" approach is for the built-in actors to just be ready to accept and integrate all API changes that come in these libraries (and if at some point they don't want them, fork). I think that's what (3) above is getting at, along with trying to front-load the integration work involved. But if we can find a way where built-in actors aren't forced to upgrade these libraries, that could be even better.

[BigLep]

(I'm working to get permissions to this repo so can do some issue cleanup/editing - slack thread)

Lets use this issue as the "Document the release process" issue.

We need to capture the steps taken and lessons learned as covered in
https://filecoinproject.slack.com/archives/C029MT4PQB1/p1718328592682279
#232

I hope too once we document the steps, we can get some more automation going (maybe building off what is suggested in #181 ).

[BigLep]

There was some work to start documenting the release process in #258

That PR has some useful conversation/ideas which we're going to backlog until someone can work this through. They basically boil down to identifying the useful bits that are still useful/relevant in actors-utils and moving them into builtin-actors.

That PR also has links to video recordings of past discussions on actors-utils.