Support for dynamic validator set

[adlrocha]

Initially, Spacenet is launched with no support for reconfiguration. The validator committee is set in genesis, and validators can't be added or remove from the committee in runtime. The first feature we want to introduce to Spacenet after launch is the ability to add/remove validators. This is also a requirement once we integrate Mir as a subnet consensus for IPC. A lot of the reconfiguration code is already there --as we have inherited it from Eudico-- but it needs to be improved (to fit the new Mir block validation architecture) and thoroughly tested.

I suggest dividing this effort into the following stages:

Stage 1: Membership from config file.

We currently provide the list of validators through the mir.validators config file. In this first stage, mir-validator should be monitoring changes to this config file to determine if the membership has changed. If a change is detected, the reconfiguration process is triggered.

• Integrate reconfiguration into Mir/Lotus integration
• Itests for reconfiguration (adding and removing validators, having inconsistent membership info between all validators, etc.).

Stage 2: On-chain membership.

Requires FVM support in Spacenet.

Instead of monitoring a config file to check membership changes, the membership information will be stored on-chain in an actor state. Mir validators will monitor the state of this actor to determine if the membership has changed and trigger the corresponding reconfiguration. Initially, we will deploy a version of the subnet actor to handle the Spacenet membership (that way we start also testing the integration of the IPC actors).

• Deploy a stripped version of the subnet actor to handle validator membership.
• Reconfiguration triggered from changes in on-chain state.
• Add segmentLength as an on-chain parameter to prevent inconsistencies (see comment for context)

[adlrocha]

This has been implemented. Follow https://github.com/consensus-shipyard/ipc-agent/issues/16 for follow-ups on testing.

Some follow-up issues were opened related to this issue: #113, #114