Implement the "naive" attestation aggregation strategy

[zah]

There is a new spec in development which specifies a "naive" strategy for attestation aggregation that will be used in the upcoming initial multi-client phase 0 testnets:
https://github.com/ethereum/eth2.0-specs/pull/1440/files

We'll need to implement a large number of validation checks before accepting and re-transmitting the incoming attestations. This depends on our ability to do GossipSub message filtering.

A slightly more sophisticated set of heuristics is being proposed by Proto here:
https://notes.ethereum.org/9Ijj2RkuRiqQYB9NOfY_9Q

They suggest another feature - the ability to prioritise certain messages for transmission.

[arnetheduck]

whoops. meant to comment that this is not necessarily scheduled for interop0

[tersec]

https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/validator.md#aggregation-selection is blocking an interop-capable 0.10.x attestation aggregation pending 0.10.x-compatible bls.Sign(privkey, signing_root):

def get_slot_signature(state: BeaconState, slot: Slot, privkey: int) -> BLSSignature:
    domain = get_domain(state, DOMAIN_BEACON_ATTESTER, compute_epoch_at_slot(slot))
    signing_root = compute_signing_root(slot, domain)
    return bls.Sign(privkey, signing_root)

[tersec]

#769

[tersec]

Current TODOs:

• once BLS code from Bls v0.10.1 #780 lands, check is_aggregator() per https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/validator.md#aggregation-selection in initial attestation aggregation #769

• add tests

• ensure is_aggregator(...) is fixed to current BLS version.

[tersec]

#769