FM-191: Execute BottomUpResolve

[aakoshh]

Closes consensus-shipyard/ipc#313
Depends on #198

The PR looks bigger than it is because it merged main, and because after running cargo update there are lots of changes to Cargo.lock and ethers also generated different code for Solidity actors. We can rebase once the dependencies are merged.

• Transform the BottomUpResolve to a message we can send to the FVM (does not include cross-messages, just for quorum certificate validation and reward tracking)
• Pass the FVM message to the inner interpreters
• Create an STM data structure for tracking background resolutions
• Add the cross-messages' root CID to the background resolution pool

[adlrocha]

The high-level idea LGTM and I like the abstractions we are using. My only concern is the same as in the previous PRs, while the protocol would work end-to-end if all peers where Fendermint-based, we may need to simplify it a bit to support mainnet interactions.

[adlrocha]

Let me see if I understand this. The idea is that:

• There is a Resolve message committing the checkpoint which includes the Cid of the list of bottom-up messages to be executed.
• If the commitment happens, the Cid of the messages are queue for resolution and a posterior proposal an execution?

I still think we may need to remove the resolution stage and directly include messages as part of the checkpoint in a first implementation. Message resolution may include additional complexity in the L2->root interaction :(

In any case, I feel this will make more sense as I move towards the implementation of the actual execution.

[aakoshh]

Yes, you got that right, and as per our sync we will implement both behaviours depending on what kind of parent we'll be dealing with. For Fendermint<-Fendermint relationships we will use this, for Lotus<-Fendermint we won't.