discv5: attacks mitigation proposal

cc @jrhea

This issue is a proposal of including the following counter-measures as recommendations into discv5 spec. Clients should make their own decision on whether to implement them or not.

## Rate limit processing of unsolicited messages
- Only _N_ unsolicited messages per unit of time should be processed. Once that limit is reached, implementations should drop requests.
- The other potential approach to rate limiting is to limit a number of threads that processes discovery requests to e.g. a single thread.

### Rationale
In a permissionless discovery network rate limiting seems the only proven counter-measure against DoS attacks. It's been figured out by @jrhea with his attacks on Prysm, Teku and Lighthouse where Lighthouse was pretty successful in resisting those attacks because of implemented rate limiting mechanism.

## New nodes should temporarily ignore unsolicited messages from unknown peers
For some period of time, depending on the implementation, new nodes should not respond to:
- unsolicited messages from unknown peers
- unsolicited messages from ANY peers

I.e. there is a trial period with only egress sessions allowed. The second option could lead to the liveness check failure in rare case, while the former requires to store any peer that the node had an egress session with.

### Rationale
This should give the node a chance to explore the network before an attacker can actively attempt to eclipse it.

An example of this kind of eclipse attack goes beyond discovery and involves application layer. For instance, in Eth1 and Eth2 attacker may quickly find a young node and offer it malicious information about the state of the chain causing the node to make a wrong decision about the sync with any potential output.

This proposal is akin to a counter-measure implemented in go-ethereum where young nodes are started to get advertised after a short period of time.