feat: Incentivization: add codec for eligibility proofs

[s-tikhomirov]

Description

Encoding and decoding data structures that store proofs of eligibility is the first step towards a PoC implementation of incentivization for Store (and, in the future, other protocols), as outlined in #1961 and RFC 73/WAKU2-INCENTIVIZATION.

Changes

The PR implements the following:

• new data types: EligibilityProof (which, for now, is thought to be a transaction id) and EligibilityStatus;
• data types DummyRequest (with EligibilityProof) and DummyResponse (with EligibilityStatus) for testing purposes (to be replaced by the request and response structures of the corresponding protocol, e.g. Store); (left for future work)
• encode and decode procedures that convert Nim data types into protocol buffers and back, respectively;
• tests to ensure that encoding and decoding work correctly: decode(encode(X)) == X.

How to test

./env.sh bash
nim c -r ./tests/incentivization/test_rpc_codec.nim

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2419-rln-v2-false

Built from 6693d21

[jm-clius]

LGTM as a start. I've added some comments below, but these can be addressed in a follow-up PR. Mostly I would decouple the coding/decoding of EligibilityProof and EligibilityStatus from the underlying req-resp protocol. This would also mean that you probably don't need a DummyRequest and DummyResponse for now - you can simply build logic and tests on the raw bytes of the eligibility messages.

[Ivansete-status]

LGTM! I just added a minor comment

[jm-clius]

@s-tikhomirov anything blocking for last changes and to get this merged?

[Ivansete-status]

Morning @s-tikhomirov!
Shall this PR be merged or is anything blocking it?

[s-tikhomirov]

Morning @s-tikhomirov! Shall this PR be merged or is anything blocking it?

Morning @Ivansete-status ! Sorry for keeping this open, I've been busy with another line of work until now (academic papers). I've been thinking of addressing existing comments in the same PR, would it be OK?

[jm-clius]

@s-tikhomirov I would suggest converting to a draft PR until you're happy that the changes are ready to be reviewed and merged. cc @Ivansete-status

[Ivansete-status]

LGTM, thanks!
I just added simple comments

[SionoiS]

LGTM

Style wise I prefer to cluster logically related lines together and add spaces in between.
It's only my personal preference though.

[jm-clius]

LGTM. I think this is a better approach rather than introducing the dummy protocol. I would like to see my comments addressed, but let's do so in a subsequent PR. This one is good to merge. Comments mostly relate to mandatory vs optional fields (in protobuf all fields should be optional for consistent, flexible wire encoding, but we can and should enforce rules around mandatory fields at the point where we decode)