Document the new VC roles and strategies features

[zah]

https://github.com/status-im/nimbus-eth2/pull/4113/files adds important new functionality for the VC client for which we need appropriate user documentation.

[cheatfate]

Beacon node's roles

Sentry nodes (validator client de-anonimization problem)

prysmaticlabs/prysm#11048

Currently there is a tightly coupled relationship between the validator and a singular beacon node. This means any validator
that is actively connected to a beacon node, will send all attestations/sync committee messages and blocks to that particular
beacon node each time. While this is fine for the average case( attestations), this brings up an attack vector during the block
proposal slot for a particular validator. Validators constantly hop between attestation subnets across epochs. By observing messages in a particular subnet, you can determine which node IPs are participating in that subnet. Once you continue recording this data across different subnets in future epochs, it is possible to have stronger guarantees of which validator IPs map to which particular public keys.
This is problematic as validators' participating in block proposals are vulnerable to DOS attacks since their IP address is leaked. Since proposal schedules are known in advance( 1 epoch - 1 slot), this gives a fair bit of time for a targeted DOS attack on a validator who has had their IP leaked.

sigp/lighthouse#3328

It is a well-known fact that IP addresses for beacon nodes used by specific validators can be de-anonymized. There is an assumed risk that a malicious user may attempt to DOS validators when producing blocks to prevent chain growth/liveness.
Although there are a number of ideas put forward to address this, there a few simple approaches we can take to mitigate this risk.
Currently, a Lighthouse user is able to set a number of beacon-nodes that their validator client can connect to. If one beacon node is taken offline, it can fallback to another. Different beacon nodes can use VPNs or rotate IPs in order to mask their IPs.

Nimbus roles

Role name	Role calls
attestation-data	produceAttestationData()
attestation-publish	submitPoolAttestations()
aggregated-data	getAggregatedAttestation()
aggregated-publish	publishAggregateAndProofs()
block-data	produceBlockV2()
block-publish	publishBlock()
sync-data	getBlockRoot() produceSyncCommitteeContribution()
sync-publish	publishContributionAndProofs() submitPoolSyncCommitteeSignatures()
duties	getGenesis() getSpec() getSyncingStatus() getValidatorsActivity() getForkSchedule() getAttesterDuties() getProposerDuties() getSyncCommitteeDuties() getStateValidators() prepareSyncCommitteeSubnets() prepareBeaconCommitteeSubnet()

Also there could be combinations

Name	Roles
attestation	attestation-data, attestation-publish
aggregated	aggregated-data, aggregated-publish
block	block-data, block-publish
sync	sync-data, sync-publish
publish	attestation-publish, aggregated-publish, block-publish, sync-publish
data	attestation-data, aggregated-data, block-data, sync-data
all	attestation, aggregated, block, sync, duty

Configuration

We going to use beacon node's URL's anchor for roles. This will help when some additional query arguments should be passed with URL, and it also keeps configuration in single place.

For example:
http://192.168.1.1:5052/#roles=attestation-data,attestation-publish
http://192.168.1.1:5053/#roles=block-proposal-data,block-proposal-publish
http://192.168.1.1:5054/#roles=all
http://192.168.1.1:5055/ also means all roles.

Before usage all the roles are got stripped from BN URLs.

Note that with roles VC should check all the configured BNs to have all the roles needed to perform validator tasks. Because user can make a mistake and supply only BNs for attestations only.

[arnetheduck]

included in #4314