chore(rln_db_inspector): include in wakunode2 binary

[rymnc]

Description

This PR includes the rln-db-inspector tool within the wakunode2 binary for ease of use.

Changes

• Removes rln_db_inspector external_config.nim, and nim.cfg
• procifies the rln_db_inspector for use with wakunode2
• adds inspectRlnDb command to wakunode2

How to test

1. First, we compile the binary

   make -j16 wakunode2

   This command will fetch the rln static library and link it automatically.

2. Define the arguments you wish to use

   export RLN_TREE_DB_PATH="xxx"

3. Run the db inspector

   ./build/wakunode2 inspectRlnDb \
   --rln-relay-tree-path:$RLN_TREE_DB_PATH 

   What this does is -
   a. loads the tree db from the path provided
   b. Logs out the metadata, including, number of leaves set, past 5 merkle roots, last synced block number

[github-actions]

This PR may contain changes to configuration options of one of the apps.

If you are introducing a breaking change (i.e. the set of options in latest release would no longer be applicable) make sure the original option is preserved with a deprecation note for 2 following releases before it is actually removed.

Please also make sure the label release-notes is added to make sure any changes to the user interface are properly announced in changelog and release notes.

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2292

Built from b026693

[alrevuelta]

minor comment but lgtm

[alrevuelta]

?

[rymnc]

still a wip, need to figure out how we can have a command for wakunode2 which doesn't accept additional args, see my message here - https://discord.com/channels/1110799176264056863/1151319265694199829/1184765875329433681

[Ivansete-status]

While I understand this approach is followed by famous apps/projects such as Geth, Docker, Git, etc., I think for now it is better to have the tools separated.

It sounds a bit weird to me having to use it with something like: ./build/wakunode2 inspectRlnDb --rln-relay-tree-path:$RLN_TREE_DB_PATH

imo, I think it would be better to have the following subcommand set:

./build/waku node ...
./build/waku rln ...
./build/waku canary ... ***
./build/waku monitor ... ***

*** Notice that I've added a line for to the current tools that we are packaging (wakucanary and networkmonitor.)

My suggestion is to postpone that rln-app unification for now and leave it for a future global unification where we will have the above commands. If not possible to postpone, I suggest following that direction so that we achieve that command-calling-convention in the future.

wdyt @alrevuelta @rymnc @jm-clius @NagyZoltanPeter @gabrielmer @SionoiS?

Also, very important to align this approach with go-waku colleagues (cc @richard-ramos @chaitanyaprem .)

[alrevuelta]

@Ivansete-status Tools such as monitor seems very specific.

[Ivansete-status]

I approve as I don't want to be a blocker