docs: summarizing how network upgrades impact Lotus and its key dependencies

[BigLep]

This is an attempt to summarize the relationships between Lotus and its key dependencies that are affected during a network upgrade. Some of this came out of discussing version schemes in filecoin-project/filecoin-ffi#468.

Checklist

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

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• 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

[BigLep]

@Stebalien or @rvagg : @rjan90 and I were speaking and we didn't have full clarity on the filecoin-ffi → go-state-types dependency. I see filecoin-ffi has a go.mod dependency on it, but the update dependency flow that @rjan90 uses doesn't involve making a go-state-type update to filecoin-ffi. Could you please shed some light so we could get this documented?

[rvagg]

filecoin-ffi uses the following types from go-state-types:

abi.ActorID
abi.ChainEpoch
abi.DealID
abi.InteractiveSealRandomness
abi.PaddedPieceSize
abi.PieceInfo
abi.PoStRandomness
abi.RegisteredAggregationProof
abi.RegisteredAggregationProof_*
abi.RegisteredPoStProof
abi.RegisteredPoStProof_*
abi.RegisteredSealProof
abi.RegisteredSealProof_*
abi.RegisteredUpdateProof
abi.RegisteredUpdateProof_*
abi.SealRandomness
abi.SectorID
abi.SectorNumber
abi.TokenAmount
abi.UnpaddedPieceSize
proof.AggregateSealVerifyProofAndInfos
proof.copy
proof.Destroy
proof.PoStProof
proof.registered_proof
proof.ReplicaUpdateInfo
proof.SealVerifyInfo
proof.SectorInfo
proof.WindowPoStVerifyInfo
proof.WinningPoStVerifyInfo
big.Int
big.NewFromGo
big.NewInt
big.NewIntUnsigned
big.Zero
network.Version

Most of the time we don't break these, so it's going to typically be safe to not upgrade filecoin-ffi's version of gst. It was important last time because we introduced a new proof type.

Probably it's a good idea to get it updated at least when we have a final go-state-types cut, but for most upgrades it may not be critical to put it in the workflow, maybe we can reduce some complexity by leaving it out until the very end when we get a final non-dev, non-rc tag. But where we are introducing new basic types, such as new proof variants, then we'll need to get it updated during the whole dev & rc cycle.

[BigLep]

Thanks @rvagg. I'll update docs accordingly.
For my own edification, what did you do to get the list of go-state-types used in filecoin-ffi? I assume gogrep, but I was struggling as a newbie to get it to work. I wanted to make sure I was even using the right tool...

[rvagg]

nothing so elegant tbh, I figured out all of the imports with a basic git grep for go-state-types and then for each I did something like git grep -E '\Wabi\.\w+' *.go */*.go | sed -E 's/^.*(abi\.\w+).*$/\1/g' | sort | uniq, a cleverer Gopher might do something more sophisticated

[BigLep]

@rjan90 : I think this is good to go. I added back the ffi dependency on go-state-types.

I also did a followup PR (#12524 ) currently targeting this PR but it could switch to master after this PR merges. It includes more discussion on the ffi dependency on go-state-types plus other things I was clueing into from thinking about this more and reviewing what was done for nv24 skeleton. This also triggered some updates to https://docs.google.com/document/d/1KKJj2COb0vIqAQh-4F7fflJjxiTgGrU9oT9B461nsgg/edit which I @mentioned you on.