[Epic] Ship RLN as part of non-native SDKs

[chair28980]

Epic label: E:RLN non-native SDKs

Summary

While setting RLN to be enabled by default in go-waku, there were linking issues against the created library (libgowaku.a and .so). Specifically, when trying to link, errors popped up due to the absence of librln functions.

In the context of go-waku, if one uses the C library and it's not built with the gowaku_no_rln tag, there's a necessity to link against librln.

For nwaku, it seems the library libwaku doesn't currently include the rln library. Hence, the issue hasn't surfaced yet but might once RLN is included.

Current Solutions & Observations:

For go-waku C-Bindings, one solution is to add documentation directing users to download librln from zerokit. This is to avoid potential errors when concatenating libraries, especially since it gets complex with dynamic libraries.

In nwaku, when linking against .a, a similar error as go-waku has been observed.

The key challenge remains how to distribute both libwaku and librln. Combining static libraries is somewhat feasible by using ar (though hacky) but the same isn't possible with dynamic libraries.

There's a complication with the waku rust bindings too. As these bindings are a layer above the C bindings, it's unusual to link both the C library and librln, especially given both rust bindings and zerokit are in Rust.

Similar issues are observed for mobile packages, though a potential workaround could be surgically adding librln inside these packages.

Acceptance Criteria

Tasks

• Mobile support go-zerokit-rln#5
• feat: c-bindings RLN support go-waku#732
• feat: c-bindings RLN support nwaku#2033