feat: RLN-proofs as a lightpush service

[jm-clius]

Problem

The challenges involved in using RLN in resource-restricted clients is well-documented elsewhere.
There are currently several promising proposals/PoCs we've considered to make RLN compatible with variously limited environments.
However, we've recently decided to deprioritise RLN proof generation in light clients to instead focus on validating RLN + Relay as main routing solution for Waku.
This implies that full/relay nodes would have to attach RLN proofs to messages published by light clients (using Lightpush) as a service to these clients.

This will have several advantages:

• resource-restricted clients can be onboarded and continue using the Waku Network as before, without needing to consider RLN proofs, key generation, membership registration, etc. More onboarded apps/clients help validate RLN+Relay in the Waku Network.
• cost implications of providing the service is relatively clear (as it's mostly tied to the RLN membership costs of the service node), which makes this service a good candidate as first PoC for incentivisation (potentially replacing "Store" as PoC service in feat: experimental incentivize store protocol #1961).
• service providers can choose to provide a certain level of free publishing in the network, helping us overcome the barrier-of-entry problems associated with acquiring RLN memberships.

Suggested solution

A simple first version of this could work as follows:

• extend lightpush service protocol to attach RLN proofs to messages received from clients
• ensure that the proof is valid (i.e. that the service node is still under the rate limit for its membership). If the service node was able to generate a valid proof publish the message, otherwise return an error in the lightpush response.
• similar logic implemented for the relay api can be used as inspiration.
• basic DoS protection need to be in place for this service to be viable. See feat: Enforce service specific rate limits #2032

Alternatives considered

In future we will want to enforce some per-client fair usage policy or other control measures, especially after we introduce a paid tier. For now, first-come-first-serve is probably a good way to get the service deployed and battle tested.

[1010adigupta]

@jm-clius would like to work on this issue, please assign

[jm-clius]

@1010adigupta thank you so much for showing interest in contributing to nwaku! Unfortunately this issue is a bit uncertain at the moment in terms of roadmap and forms part of a complex milestone that is earmarked for ownership by our research team. A self-contained task is usually better for outside contributions. I've therefore removed the good first issue label. Perhaps there's another self-contained task in the nwaku repo that may be a good entry point? cc @Ivansete-status for suggestions

[shash256]

Now that we have merged #2768 and service specific rate limits is being tracked in a separate issue, I am closing this now. Feel free to re-open if anything else is missing that should be a part of this issue.