doc: clarify max shard value on CLI args

[fryorcraken]

I started this PR because it bugged me that I could not simply start wakunode2 and connect to it via wakucanary because wakucanary wants shards:

▶ ./build/wakucanary -a=...
INF 2024-06-28 13:59:19.881+10:00 Cli flags                                  tid=2317631 file=wakucanary.nim:164 address=/ip4/0.0.0.0/tcp/60000/p2p/16Uiu2HAm6AKL8iczGNguEwwcJGmCmgAS2cpTRve4UkMExtwt45gA timeout=10s protocols=@[] logLevel=INFO
ERR 2024-06-28 13:59:19.883+10:00 Relay shards initialization failed         tid=2317631 file=wakucanary.nim:209 error="invalid shard count"
ERR 2024-06-28 13:59:19.883+10:00 The node has some problems (see logs)      tid=2317631 file=wakucanary.nim:283

In the good default value spirit, we should be able to run the binary with minimal config out of the box, without having to fiddle things.

The good default at the moment should either be:
1, TWN (aka RLN Relay protected network)
2. Status prod

There is value in doing either. However, for the sake of dogfooding and pushing RLN further, I believe (1) should be default. Until we can get RLN on Status network.

So, the proposal I'd like to make before I proceed forward is to change all default parameters to TWN, meaning that a user will have to pass a API address for eth client to play with nwaku.

This would mean something similar to nwaku-compose, but without postgres.

Cc @waku-org/nwaku-developers

cc @gabrielmer some suggestions in there in terms of handlng shards, in reference to #2163

[github-actions]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Details:

Unknown release type "doc" found in pull request title "doc: clarify max shard value on CLI args".

Available types:

• chore
• docs
• feat
• fix
• refactor
• style
• test

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2856

Built from c62a8f8

[fryorcraken]

I am guessing this is incorrect as you'd need to have shards configured (ie 0 to 7 ) to apply an auto sharding logic as the result of the autosharding logic depends on the shard range available.

[gabrielmer]

so currently we deduce the amount of shards based on the number of pubsub topic configured. In other words, the --pubsub-topic parameter shows all the possible shards that exist

To avoid ambiguity, in the PR deprecating the pubsub topic concept will add a new CLI flag which will indicate the number of shards in a network

[fryorcraken]

@gabrielmer I think this is needed in #2723

[fryorcraken]

Something useful @gabrielmer