feat(enr): added support for relay shards field

[LNSD]

This PR introduces the Static Sharding ENR extension.

• Split the waku_enr module into three submodules: capabilities, multiaddr, and sharding.
• Added the rs and rsv extension implementation.
• Added some tests covering the sharding extension.

[alrevuelta]

left some comments.

@kaiserd Remember we talked last week about sharding. Do we consider the spec ready and moving to implementation?

I raised my concerns here and here but as a tldr:

• I think waku should handle discovery only on waku shards.
• I dont think we need this hierarchy of cluster + index. just shard index.
• I think we should cover way less shards. quality and not quantity.
• I dont think we need static sharding, just automatic. I wouldn't justify the need of static wharding with the MVP.
• imho static sharding would be waku's dystopia. companies pushing their users to shards they control with no guarantees on decentralization, privacy, etc. all shards should be equal = managed by the protocol = auto sharding.
• if an app wants static shards, fine, fork the network (like bsc, gnosis, ethclassic or even eth networks). wouldn't be difficult with a network-id in the ENR (which acts as kind of the shard-cluster but more generic)

These discussions, belong to here, so lets reply in there.
vacp2p/research#174

But raising it again here since we started with the implementation.

[alrevuelta]

can we perhaps merge the following into just.

var builder = EnrBuilder.init(enrPrivKey, seqNum = enrSeqNum)
builder.withWakuRelaySharding(shardCluster, shardIndices)

so we avoid having to init RelayShards first? and then passing it?

perhaps a nitpick but withSharding instead withWakuRelaySharding?
so .withSharding().withCapabilities().withMultiAddress() etc.

[LNSD]

perhaps a nitpick but withSharding instead withWakuRelaySharding?
so .withSharding().withCapabilities().withMultiAddress() etc.

If you add this chained builder pattern, you lose the possibility of one of those methods to return a Result, which is very convenient.

[LNSD]

so we avoid having to init RelayShards first? and then passing it?

I added the needed methods for the static sharding discv5 implementation. I am reluctant to add more convenience methods because they "might be handy".

We can always extend the implementation once this part is used.

[kaiserd]

@alrevuelta

Do we consider the spec ready and moving to implementation?

Given the tight MVP time-line: yes. @jm-clius wdyt?
As you suggested, I will post here: vacp2p/research#174

[Ivansete-status]

The PR looks great!
However, I think we could have some more details in error handling that maybe worth adding.

[Ivansete-status]

In this case we are losing the possible error given by fromIndicesList.
I'd try to chain the possible errors back to the caller as much as possible by returning a Result[Option[..], string]

[LNSD]

In some cases, for convenience reasons, we don't want to bubble up the error and the probability of this happening (in normal operation conditions), I added a debug log so we can identify when this is occurring.

[jm-clius]

Do we consider the spec ready and moving to implementation?
Given the tight MVP time-line: yes. @jm-clius wdyt?

@alrevuelta @kaiserd I think so too, given that this was also discussed in some detail with Status and addresses a large number of concerns (granted we're still waiting for more detailed feedback from them on the RFC). Will provide more comments on the related issue to keep this PR cleaner.

[jm-clius]

LGTM! Thanks for making progress on this.