Do not require non-aggregators to subscribe to attnets

[djrtwo]

As suggested by @AgeManning and discussed on the recent networking call, this PR distinguishes from an aggregating and non-aggregating beacon committee member for the purposes of attestation subnets.

• Aggregators -- fully subscribe to the attestation subnet to receive newly published attestations for aggregation
• Non-aggregators -- Only find sufficient peers on the attestation subnet (rather than subscribe) to allow for publishing of attestations. Reduces bandwidth requirement on the node, and keeps attnets small for quick propagation.

[mkalinin]

Do I understand correctly that after this change the mesh of a subnet will consist only from aggregators assigned to particular slot? If yes, doesn't it increase a surface for eclipse attack?

[zilm13]

plus to @mkalinin: open subnetwork of many nodes provides better security properties than small subnetwork even if its private.
Plus average Kademlia table of long running node consists of ~150 peers, which means you will have 2-3 nodes(/64) from any subnetwork in it (if you have only validators in network) according to the previous spec to start search from an 0 with new spec.

[djrtwo]

Do I understand correctly that after this change the mesh of a subnet will consist only from aggregators assigned to particular slot?

No, the mesh consists of the persistent committee plus the aggregators for a range of slots (something like 5 to 20 slots worth of aggregators, assuming aggregators join some amount of slots in advance to prepare). Persistent committees are simulated in phase 0 (see Phase 0 Attestation Subnet Stability)

which means you will have 2-3 nodes(/64)

Assuming that there is a distribution of validators across nodes and that each validator subscribes to a random subnet (rather than just each node), then there would be multiple more than 2-3 nodes of attnet capabilites in your routing table.

[djrtwo]

addressed comments @protolambda

[protolambda]

LGTM