Harmonize P2P interface with libp2p/gossipsub message-id and support GOSSIP_MAX_SIZE

[tersec]

#122 discusses a pair of issues in terms of where the code changes need to occur, some in nim-beacon-chain validation, and others in terms of changes required for lower-level gossipsub validation. This issue tracks the latter.

In particular, from #122 (comment) it contains:

In terms of nim-libp2p APIs, remaining are a couple of things, validation-wise:

* https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#topics-and-messages says `Each gossipsub message has a maximum size of GOSSIP_MAX_SIZE. Clients MUST reject (fail validation) messages that are over this size limit. Likewise, clients MUST NOT emit or propagate messages larger than this limit.` but the current validation API requires specifying a specific topic, for a constraint that applies to all topics. @dryajov has said he'll add direct support for this in `nim-libp2p`.

* https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#topics-and-messages and https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#why-are-we-overriding-the-default-libp2p-pubsub-message-id discuss that:

For our current purposes, there is no need to address messages based on source peer, and it seems likely we might even override the message from to obfuscate the peer. By overriding the default message-id to use content-addressing we can filter unnecessary duplicates before hitting the application layer.

such that The message-id of a gossipsub message MUST be: message-id: base64(SHA256(message.data)). It's not clear this information should available at all to the Ethereum 2 networking layer as such, or compliant with the libp2p specification.

In terms of nim-libp2p APIs, remaining are a couple of things, validation-wise:

* https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#topics-and-messages says `Each gossipsub message has a maximum size of GOSSIP_MAX_SIZE. Clients MUST reject (fail validation) messages that are over this size limit. Likewise, clients MUST NOT emit or propagate messages larger than this limit.` but the current validation API requires specifying a specific topic, for a constraint that applies to all topics. @dryajov has said he'll add direct support for this in `nim-libp2p`.

* https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#topics-and-messages and https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/p2p-interface.md#why-are-we-overriding-the-default-libp2p-pubsub-message-id discuss that:

For our current purposes, there is no need to address messages based on source peer, and it seems likely we might even override the message from to obfuscate the peer. By overriding the default message-id to use content-addressing we can filter unnecessary duplicates before hitting the application layer.

such that The message-id of a gossipsub message MUST be: message-id: base64(SHA256(message.data)). It's not clear this information should available at all to the Ethereum 2 networking layer as such, or compliant with the libp2p specification.

And from #122 (comment) :

The message-id of a gossipsub message MUST be: message-id: base64(SHA256(message.data)).

This is currently impossible to do in some (most?) implementations as the gossipsub RPC message isn't exposed to the application, consequently the neither the message-id nor the from fields are accessible. Currently, the nim-libp2p doesn't expose this functionality either.

Given that Eth2 networking spec mandates this for all clients, we should propose this changes to be included in the gossipsub spec.

[dryajov]

This is most likely related to our current issues with gossipsub.

[arnetheduck]

fixed