feat: determine bootstrap behavior based on sharding type

[adklempner]

This is a feature or change request

Context

the defaultBootstrap option was set in an effort to keep the code as agnostic as possible in terms of reliance to Logos/Status infra. This was done when js-waku was one monolithic codebase.

Now, js-waku is a mono repo with agnostic implementation of the protocols (core, message-encryption, etc) and an opinionated, good default and easy to use interface @waku/sdk.

Moreover, with the introduction of the Waku Network Gen 0, a new fleet of nodes with RLN and autosharding enables has been deployed. This fleet should be used as bootstrap when using autosharding and RLN.

The old fleet only supports named sharding on default pubsubtopic.

Problem

Currently the default bootstrap behavior is to connect to old Waku (namespace, default pubsub topic) fleet.

js-waku now supports namespace sharding (to be deprecrated) and autosharding. The default bootstrap behaviour should match the sharding strategy so it can hit the right fleet.

Proposed Solutions

The fleet to use for bootstrapping should be determined by whether the Waku node is setup to use named sharding or auto sharding.

If using static sharding, then the developer must provide an enrtree for bootstrapping.

Notes

Consider dropping the defaultBootstrap argument to make the API simpler.

If a developer pass their own bootstrap node, then it should override the default behaviour and not connect to Waku fleet.

• Depends on feat: Peer management with shard as a dimension #1505

[chair28980]

We should get clarity on what fleet we should be using to bootstrap js-waku on The Waku Network.

[weboko]

As of now js-waku uses TWN (thought without RLN) and RLN as a service should be provided soon so there is no reason to go back to named sharding.

For TWN use cases js-waku node need to know contentTopics or shardInfo in advance to be bootstrapped properly.

defaultBootstrap is still relevant as it enabled discovery approaches that are useful for end user.

Considering it I think Proposed Solution section is met and we can close it.

@adklempner , please, re-open if you think otherwise.