feat: support sharded peer connectivity and config

[chaitanyaprem]

Problem

As of now peermanager takes a single config of max connections and max peers. This is fine as long as all peers support all shards in the network. The issue comes when different peers support different shards like in case of status community sharding where all relay nodes(desktop instances) don't need to support all shards rather the shards that they are interested in(i.e communities that they are part of).

We need to modify the peerConfig (maxPeers, maxConns) to be based on per-shard and list of protocols to be used on the shard such as relay, lightpush, filter etc.

Suggested solution

Each protocol registers with peerManager its config that is required. config can be like this:

• minPeers to be connected
• numPeers (not connected) to be maintained in peerstore for immediate switchover

For each shard the node is subscribed to peermanager will try to ensure above config is met i.e enough peers are available to connect and are connected.

overall maxPeers and maxConnections for the node would then be determined by shard-count* protoconfig per protocol.

question: how to limit some sort of overall config as per application? maybe strategies can be defined whether to use peers that support multiple shards or dedicated shards.

Approach still TBD

cc @waku-org/nwaku-developers something to think of for nwaku as well.

Alternatives considered

None

Acceptance criteria

TBD