feat(rpc): internal F3 RPC methods to power go-f3 sidecar

[hanabi1224]

Summary of changes

Part of #4644

To construct a go-f3 node, an EC(expected consensus) backend is required. When we run a f3 node as sidecar, we cannot directly pass an EC backend, instead, we expose a set of RPC methods on forest side, and implement a go EC backend with RPC client.

Some design considerations:

• performance may or may not be an issue. We start from naive json data serialization and optimize it later.
• implementing RPC in the P2P layer might be over complicated and harder to debug or troubleshoot

// EC backend interface defined in `go-f3`
type Backend interface {
	// GetTipsetByEpoch should return the tipset immediately before the one requested.
	// If the epoch requested is null, it returns the latest not-null one.
	GetTipsetByEpoch(ctx context.Context, epoch int64) (TipSet, error)
	// GetTipset returns the tipset with the given key.
	GetTipset(context.Context, gpbft.TipSetKey) (TipSet, error)
	// GetHead returns the current head tipset of the chain
	GetHead(context.Context) (TipSet, error)
	// GetParent returns the parent of the current tipset.
	GetParent(context.Context, TipSet) (TipSet, error)
	// GetPowerTable returns the power table at the tipset given as an argument.
	GetPowerTable(context.Context, gpbft.TipSetKey) (gpbft.PowerEntries, error)
}

// lotus code for constructing a go-f3 node
	ec := &ecWrapper{
	ChainStore:   params.ChainStore,
	StateManager: params.StateManager,
}
verif := blssig.VerifierWithKeyOnG1()

module, err := f3.New(mctx, params.ManifestProvider, ds,
	params.Host, params.PubSub, verif, ec)

// with this change, we can construct EC backend for a sidecar f3 node like this
ec := ecrpcclient.New(forest_rpc_endpoint)

Changes introduced in this pull request:

• implement F3.* RPC methods
• API parity tests are not applicable
• go EC implementation and tests (TODO: run go tests in CI)

Reference issue to close (if applicable)

Closes

Other information and links

Change checklist

• I have performed a self-review of my own code,
• I have made corresponding changes to the documentation,
• I have added tests that prove my fix is effective or that my feature works (if possible),
• I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

[LesnyRumcajs]

go EC implementation and tests (TODO: run go tests in CI)

Let's have a tracking issue for that.

[LesnyRumcajs]

That's a pretty massive method. Can it be refactored?

[hanabi1224]

There's a lot of duplicate code handling different variant of power state, v12-v14 has already been simplified with a macro. v8-v11 are all different. I guess I can update fil-actor-states to unify the API for v8-v11 to further simplify the code with a single macro, how about doing that in a subsequent PR since it requires a release of fil-actor-states

[hanabi1224]

ChainSafe/fil-actor-states#324

[LesnyRumcajs]

Does it require a release or can we move that logic entirely to Forest's shim? In any case, I'm good with that as long as it's indeed a follow-up and not an abandonware issue. :)

[hanabi1224]

Yeah I can move the entire thing to forest as well

[hanabi1224]

Let's have a tracking issue for that.

@LesnyRumcajs #4652

[ruseinov]

nit: since this match is so long - perhaps it would be more readable to separate this into helper methods?

[hanabi1224]

This is tracked by ChainSafe/fil-actor-states#324

[ruseinov]

This looks good to me apart from a massive match block, but I don't consider it a blocker.

[ruseinov]

I would introduce a CI job that runs the EC tests too, perhaps a different PR is in order, not sure how much of a priority that is though.

[hanabi1224]

I would introduce a CI job that runs the EC tests too, perhaps a different PR is in order, not sure how much of a priority that is though.

@ruseinov Will do that in a subsequent PR since running the Go tests is a bit more complicated than normal as they depend on a running forest node.