feat: Autosharding API for req-resp protocols

[chair28980]

This tracks the work necessary in each client to provide API(s) to applications using req-resp protocols (store, lightpush, filter, etc.) with optional pubsub topic arguments. Each client should then use autosharding to determine the associated shards on behalf of applications. Note that underlying protocols should not be affected and each client implementation should locally populate pubsub topic fields with the shards hashed from content topics received via the API.

Priority: Critical for launch

[chair28980]

waku-org/research#3

@danisharora099 @weboko

Per the research issue, can y'all verify if this is required for JSWaku and assign ownership as necessary. Thank you!

[adklempner]

Weekly Update

• achieved: derive pubsub topic from content topic in encoders/decoders when autosharding is specified
• next: node config should specify static sharding or autosharding. implement autosharded topics in all req-resp protocols

[fryorcraken]

Do note that for this epic, it is fine to expect a js-waku node to only belong to one shard and to have the developer pass this "shard" (ie, application and version part of the content topic) at node creation time.

[adklempner]

Weekly Update

• achieved: config node for static/autosharding, test all protocols against autosharding RPC endpoints on nwaku
• next: config application and version on node creation, only discover nodes of same shard

[adklempner]

Weekly Update

• achieved: all protocols can be configured to use autosharding for determining pubsub topics
• next: make autosharding the default behavior when running js-waku