Refactor randao core signed data implementation

[corverroos]

Problem to be solved

While refactoring signature verification into its own standalone function, we discovered that randao signatures cannot be verified on their own, since they do not contain the raw data that we signed, which is the epoch. We previously relied on the associated duty/slot. This creates additional coupling and means we cannot extract and decouple signature verification properly.

Before #217 can be completed, we need to address this issue.

Proposed solution

• Introduce our own custom ETH2 type called eth2util.SignedEpoch:

type SignedEpoch struct {
  Epoch eth2p0.Epoch
  Signature eth2p0.BLSSignature
}

• Refactor eth2util.EpochHashRoot as a method of this type.

• Introduce a new core.SignedEpoch wrapper of eth2util.SignedEpoch implementing core.SignedData, exactly the same as the other siigned data implemenations.

• Rename DutyRando to DutySignature, use that duty in DKG.

• Add a new duty type, DutyRandao, use this duty in charon run. (this is a breaking change)

• Use core.SignedEpoch for DutyRandao instead of core.Signature.

• Note we are not staying backwards compatible, DutyRandao (and therefore DutyPropose) will not work in cluster with a mix of previous and later versions since the wire value of DutyRandao is changing.

• Decouple Randao signature verification from core.Duty.Slot

[thomasheremans]

Paused until v1.0

[corverroos]

Yeah, this will preferably require breaking changes to the API.

To keep backwards wire compatibility, we need to refactor randao to a new duty type enum, and send both enums from the new servers (which will result in errors in older servers) and convert the old duty type to the new duty in parsigex (for charon run only not dkg) which introduces more coupling, which is what we are trying to fix.

If this can go in with breaking change, then it would be best.

[dB2510]

Closed by #1019