idea(rln-relay): use rln-relay as a sub-protocol of waku-relay

[rymnc]

Background

1. Waku Relay
2. Waku RLN Relay
3. Pubsub topic message validation
4. RLN Group Sync Layer

Details

In it's current state, waku rln relay is perceived as a protocol, whereas, it is a thin layer over waku-relay. It does not have a protocol id, as it uses waku-relay to send and receive messages. waku-relay provides message validation for a given pubsub topic, and we use the rln validation logic there. Therefore, all waku-rln-relay does, is message validation on a given pubsub topic.

There are misconfigurations possible with waku-rln-relay, when operators would like to run spam prevention, but do not realize they need to enable the waku-relay protocol for it to mount correctly.

This proposal aims to feature flag rln/rate-limiting within waku-relay, where it is mounted in tandem with waku-relay, and each form of message validation in rln (which is directly related to the group synchronization) is a different pubsub validator that is applied depending on the configuration passed to waku-relay.

Semantically, this aligns more with the rln/rlnp2p vision and also clears confusion re: the real function of waku-rln-relay.

Acceptance criteria

• TBD: will be fleshed out if proposal passes

[fryorcraken]

@alrevuelta @jm-clius should this be part of Epic 3.2? ?

[jm-clius]

Not sure how relevant this still is (I think a lot of the work here has already been done @rymnc ?). Nevertheless, no Epic 3.2 is meant to track the critical MVP for RLN in production, where this is a general improvement not part of the Gen 0 milestone (i.e. we don't need this to be closed to launch).

[rymnc]

not planned since this will be replaced with pluggable validators.