Externalize verification of checkpoint to dedicated module

[ranchalp]

The existing ISS implementation verifies the signatures of a stable checkpoint received and that the signers are members from the previous membership (as the checkpoint of an epoch $e$ is signed by members of epoch $e-1$).

The ISS module contains a struct field iss.Memberships that stores the memberships of the current epoch and the following iss.Params.ConfigOffset epochs. This means that if a checkpoint for epoch e > iss.epoch + iss.Params.ConfigOffset + 1 is received, the ISS module has not way to verify the validity of the signers (in that they may not be part of the membership responsible to sign the epoch).

At the moment, the code logs a huge warning for this case and continues executing 'believing the validity of the membership contained in the checkpoint', but the correct behavior would instead be verifying in some other way. Many options are possible, for example:

1- Buffer and sort checkpoints to verify them in order (should one receive an earlier checkpoint after a later checkpoint).
2- Check in a parent subnet (in the IPC hierarchy) the membership
3- Catch-up in any other way

As there are many application-specific ways to resolve this edge case, in the case where the ISS module cannot verify the validity of the signers, the validity should be externalize to a dedicated module that handles this.

[matejpavlovic]

Putting this in the backlog, since it involves a non-trivial implementation effort if we want to make it actually work (which would mean implementing the fetching of new membership from the external source). Nothing too complex in principle, but it requires interacting with external systems.