feat(rln-relay): group management interface

[staheri14]

Problem

Right now, group management logic is intertwined with the mounting process of rln-relay. Due to this, we currently have two different mounting procedures, namely, static and dynamic. This is while the two procedures only differ in the group management part and are almost identical in the rest. Sticking to this design means that in the future, if a different group management logic is to be introduced, a new mounting process should be implemented. This is against the modularity and extensibility of the design.

Suggested solution

Group management in Rln-relay can be treated as a stand-alone module whose sole responsibility is to obtain group-related updates. The updates then should be properly available to a waku-rln-relay node to consume.
The suggested solution is to define a proper group manager interface. Each WakuRLNRelay will hold a member field of that type. As a result, any implementation of that interface can be plugged into a WakuRLNRelay node without touching the rest of its internals. A WakuRLNRelay node then makes use of its group manager to get group updates and use them as necessary (e.g., update its Merkle tree).

Additional context

This is a significant step toward positioning RLNp2p as a stand-alone module with extended utilities like group management which is not available in the RLN library.

Acceptance criteria

• Identifying an API for the group manager
• Converting the dynamic on-chain group management logic to a separate module satisfying the said API
• Updating the internals of rln-relay mounting procedure to access to the group updates through an instance of a group manager

[rymnc]

Addressed in #1465. Will close this upon its merge.