feat: Service peer selection on specific shards

[chair28980]

Currently a service peer (e.g. a store node) is either provided by the application or it expects the peer manager to suggest a suitable service peer (selectPeer()). This task focuses on the latter: peer manager should provide ability to find service peers for a specific shard, based on the content topic that the application is interested in (e.g. an API call to selectPeer(Protocol, ContentTopic)), or kick off an ad-hoc discovery process until a suitable service peer is found. Client APIs (for filter, lightpush, peer-exchange) should automatically make use of this mechanism if the application does not explicitly set the desired service peer.

Priority: critical for launch

[SionoiS]

I've looked at the code and it seams easy to do.

The hard part is the architecture doesn't make it easy to access waku_dscv5.

Handlers would call selectPeer() then if none is found launch some discovery process.

[SionoiS]

Architecturally is seams that calling discv5 to find peers with specific shard and caps should be done at the app level.

Protocols clients impl. should not know about the discovery process.

[SionoiS]

Extracting all the protocols (leaving only mounting) from waku_node is harder than I thought. The external API sit at the node level and would have to change to app level.....

[SionoiS]

Weekly Update

• achieved: peer manager can filter peer by shard, filter discv5 bootstrap nodes by shard, external APIs moved out of node folder
• next: refactor APIs handlers to discover peers if none is found in peer manager with the required capability

[SionoiS]

Weekly Update

• achieved: newly refactored STORE REST API handler that trigger discv5 peer search when needed.
• next: refactor other APIs

[SionoiS]

Weekly Update

• achieved: Filter, Store, Light push REST APIs discovery handler (a rework of the previous solution)

[SionoiS]

Weekly Update

• achieved: REST APIs discovery handlers PR merged

[SionoiS]

Done