feat: allowing configuration of application level callbacks

[gabrielmer]

Description

We noticed that libwaku doesn't automatically configure a callback for receiving Relay messages when creating a node. Currently, the user has to manually subscribe to each topic providing their callback.

In order to make libwaku more user friendly, we need to be able to register all the event-emitting callbacks automatically when creating a node. Therefore, I added a WakuCallbacks type where a user can pass all the different callbacks they need when creating a node. Currently, only relayHandler is defined in the type, but in a following PRs new callbacks will be added (for example, a callback that runs every time a topic health changes)

Changes

• introduced WakuCallbacks type for application-level callbacks
• added setupCallbacks procedure that adds the configured WakuCallbacks
• modified Waku.new() to accept WakuCallbacks and properly set them up
• introduced a callbacks parameter to libwaku's createWakuso we can configure in node creation all the event-emitting callbacks

Issue

#3076

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3206

Built from 8b2241a

[Ivansete-status]

Thanks so much for it! I like the concept very much but I think we need to address a couple of minor details :)
Nice PR! 🥳

[richard-ramos]

Would set_event_callback stil lbe necessary with this new AppCallbacks feature?

[gabrielmer]

Would set_event_callback stil lbe necessary with this new AppCallbacks feature?

My understanding is that it is still necessary because there's two type of callbacks - the callbacks at the nwaku's application level which in libwaku we use to emit events (the type of callback of this PR), and a callback defined at libwaku's client to handle all these events emitted by the application level callbacks.

Or in other words the callbacks of this PR are run whenever something in nwaku happens, for example when a Relay message is received.
The nwaku user can execute whatever (Nim) code they want whenever that happens. And in libwaku we take advantage of it by emitting events on those callbacks, which will be then handled by the callback set in libwaku's set_event_callback

Let me know if I might be missing something or if you think of a way to simplify this structure :)