feat: strategy for managing lightpush and filter clients with status sharding

[chaitanyaprem]

Problem

As of now filter and lightpush clients are limited either via rate-limiting or number of filter subscriptions/peers in a global config.
But considering status sharding approach of having 2 common shards (32 and 64) and upto 100 community specific shards a different strategy in allowing particular number of clients per protocol per shard is needed.

Suggested solution

one simple strategy is to have a total number of clients to be supported as a config and just divide by number of shards local node is supporting. e.g: if total filter clients to be allowed is 1000 and node supports 100 shards then 10 clients per shard. But this may not be valid in case of application like status since common shards would be used by all app instances whereas community specific shards will be used by a small subset of overall nodes.
which means we will have to take some sort of shard level configuration as input or have 2 default configs (1 for common shards and 1 for community shards).

Approach TBD

cc @waku-org/nwaku-developers

Alternatives considered

TBD

Acceptance criteria

have tests or simulations to verify the strategy works with many shards.