feat: Waku API's subscribe

[fryorcraken]

Introduced a new subscribe function to the Waku API.

Problem / Description

Developer need a simple API to receive messages.

Solution

See TODOs / Notes

API

interface IMessageEmitterEvents {
  [contentTopic: string]: CustomEvent<Uint8Array>;
}

interface IWaku {
	messageEmitter: TypedEventEmitter<IMessageEmitterEvents>;
	subscribe(contentTopics: ContentTopic[]): Promise<void>;
}

Usage

const contentTopic = "/some/0/content-topic/proto"

// Setup event listener and callback
waku.messageEmitter.addEventListener(contentTopic, (event) => {
	const payload:UInt8Array = event.detail;
	// process payload
  });
});

// trigger node subscription
await waku.subscribe([contentTopic]);

TODOs / Notes

Specs: logos-messaging/specs#86

• Remove callback in favour of event emission
• Demonstrate integration with encryption
• Demonstrate integration with encryptio and reliable channels

Related to #2216

---

Checklist

• Code changes are covered by unit tests.
• Code changes are covered by e2e tests, if applicable.
• Dogfooding has been performed, if feasible.
• A test version has been published, if required.
• All CI checks pass successfully.

[weboko]

My intention was to go a bit different direction:

type WakuMessage = {
  Payload: Uint8Array;
  ContentTopic: string;
  Ephemeral: bool;
  // maybe some other fields
};

type MessageListener = (event: CustomEvent<WakuMessage>) => void;

Interface IWaku {
  subscribe(contentTopic: string, cb: MessageListener): void;
}

What I propose is not ready yet, but first steps are set in #2583 in AckManager.

Another hard restriction, I think we have, is that IFilter, ILightPush and IStore must stay the same they are. That is why I am adding .send as new method on IWaku and believe the same should be done for .subscribe.

As for which approach to use - .addEventListener or .subscribe - I don’t really care but I decided to continue with .subscribe because call to this method implies some network operation of setting up the subscription.

Internals of FilterSDK, as I wrote them, accommodate for both - https://github.com/waku-org/js-waku/blob/master/packages/sdk/src/filter/subscription.ts#L57

All in all I think .subscribe should be implemented after .send.

[weboko]

This is small POC how I see it #2671

[fryorcraken]

Another hard restriction, I think we have, is that IFilter, ILightPush and IStore must stay the same they are.

Why?

That is why I am adding .send as new method on IWaku and believe the same should be done for .subscribe.

Yes, this present PR adds .subscribe to IWaku.

[fryorcraken]

As for which approach to use - .addEventListener or .subscribe - I don’t really care but I decided to continue with .subscribe because call to this method implies some network operation of setting up the subscription.

I am suggesting .addEventListener for a smoother and more uniform devex.

Actually, looking at the current API, we can do better by handling both errors and message via event listener to get the smooth UX.

[fryorcraken]

Superseded by #2683

I removed the filter changes to keep the PR cleaner. cc @weboko