feat: support RateLimitProof and Ephemeral attributes in wakunode2 JSON-RPC/REST APIs

[richard-ramos]

No description provided.

[rymnc]

I believe there was some conversation around skipping the ephemeral flag in RPC/REST responses due to the nature of it being only of interest to peers and not to the end user.

cc: @jm-clius wdyt?

[jm-clius]

Eh, yeah, I think we have some inconsistencies here:

• RateLimitProof is not yet added to 14/WAKU2-MESSAGE and probably shouldn't be as we want to move this spec to stable very soon. If this is necessary/useful on the APIs, we can/should add it.
• There was some discussion on the value of ephemeral on the APIs. Currently it will be returned in responses on the JSON-RPC API but is not available when posting messages or on the REST API. I think the simplest thing is just to add this field to both APIs. @rymnc

[LNSD]

One question, is this a bug? Or a missing feature and, therefore, a feature request?

For me, a bug 🐛 is:

A feature implementation that is not working as per its specification.

For example, the waku store response's next page's info contains an empty cursor when it should be returning a valid cursor.

Suppose a behavior is not described as part of the feature's specification and is not present in the implementation. In that case, we are discussing either a defect (if it makes the functionality unusable) or a feature enhancement/improvement request.

[richard-ramos]

I admit that I did not spend much time thinking which category to use with this issue. Let's change it to whatever makes more sense!