chore: sending msg hash as string on libwaku message event

[gabrielmer]

Description

As previously discussed, it makes more sense for application clients to use message hashes as hex strings instead of a string representation of a byte array.

In this PR, we're modifying the usage of message hashes in libwaku and in the REST API to receive and return the message hashes as hex strings. This change only applies for the interactions with the message hashes and with pagination cursors (which are themselves message hashes). Everything else remains untouched and other fields such as payload and meta are still sent as base64 strings.

Changes

• creating WakuMessageKeyValueHex and StoreQueryResponseHex types to be used when interacting with application clients
• returning message hashes in libwaku's JsonMessageEvent and waku_store_query as hex strings
• returning message hashes in Store REST API as hex strings
• updating tests

A PR updating the REST API's docs will be opened once this PR is merged. Or shall we define a new endpoint for backward compatibility? Another option is to accept both byte arrays and hex strings in the API and check in the endpoint which one it is

Issue

#3076

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3234

Built from 9fda9e4

[Ivansete-status]

@gabrielmer - ah, sorry but I can't approve that one now, unless you convince me hehe. I think is fine passing the msg_hash as byte array because is more efficient than dealing with string. On the other hand, the host code (Go, Rust, etc) should easily show the msg_hash representation in a readable format. Let me know if that causes a big trouble somewhere :)

[gabrielmer]

@gabrielmer - ah, sorry but I can't approve that one now, unless you convince me hehe. I think is fine passing the msg_hash as byte array because is more efficient than dealing with string. On the other hand, the host code (Go, Rust, etc) should easily show the msg_hash representation in a readable format. Let me know if that causes a big trouble somewhere :)

Well, I don't know if I can convince you about the change itself, but at least I might be able to convince you that the opposite is true of what you mentioned - dealing with a string is more efficient than dealing with the byte array lol.

If you see, the events are not serialized and deserialized, they are sent as a json-string:

nwaku/library/libwaku.nim

Lines 92 to 95 in 625c8ee

	proc onReceivedMessage(ctx: ptr WakuContext): WakuRelayHandler =
	return proc(pubsubTopic: PubsubTopic, msg: WakuMessage) {.async.} =
	callEventCallback(ctx, "onReceivedMessage"):
	$JsonMessageEvent.new(pubsubTopic, msg)

In other words, when we send that byte-array, we are sending the string representation of a byte array, not the bytes directly.

The host has to then parse that string, convert it to an actual byte array and then convert it to the string representation of the hash. It's both less efficient and it adds extra/unnecessary work from the host's code to have to parse the string representation of a byte array

[Ivansete-status]

@gabrielmer - you are absolutely right my friend. I think I'm starting to get convinced ;P

[Ivansete-status]

Approving after the agreement to focus on retrieving all the information from libwaku in the most readable format, by default :)

[gabrielmer]

Moving this PR back to draft, will reopen it for review once the hex string format is used all across libwaku and REST

[gabrielmer]

Maybe it's better to define a WakuMessageHashHex or HexString type and use it instead of just string?

LMK if it makes sense and if it adds value