chore: update c-bindings rfc to use callbacks

[jimstir]

By @richard-ramos
Was Approved
Reference pull request: vacp2p/rfc#609

@Ivansete-status:

Here's the updated RFC using the callback API you proposed for nwaku c-bindings. Notice that some functions in here receive a callback, while they don't in nwaku, (waku_start and waku_stop can fail in go-waku). Should we have the same signature in nwaku even if it is not possible for it to fail on start/stop? (the onErrCallback will never be called there)

Something else that I wanted to discuss with you is how are we going to handle functions that do not receive a string result. for example these:

// Get number of connected peers
extern int waku_peer_cnt(WakuCallBack onOkCb, WakuCallBack onErrCb);

// Determine if there are enough peers to publish a message on a topic. Use NULL
// to verify the number of peers in the default pubsub topic
extern int waku_relay_enough_peers(char* topic, WakuCallBack onOkCb, WakuCallBack onErrCb);
The peer count is supposed to be a number, and the second function is supposed to be a boolean. In this PR I'm returning the string representation of a number and a boolean, but IMO it's ugly. Do you think we should have instead different types of callbacks instead? something like this:

typedef void (WakuStringCallBack) (const char msg, size_t len_0);

typedef void (*WakuIntCallBack) (int value);
Then WakuIntCallBack could be used both for numbers and booleans (returning 1 or 0).
What do you think?