fix(store)!: use pubSubTopic from DecodedMessage for createCursor

[danisharora099]

Problem

For Store protocol, DecodedMessage/Decoder as well as createCursor take in pubSubTopic while only the former is treated as the source of truth when using it.

Solution

Since DecodedMessage now always has PubSubTopic, we can abstract away setting it from the API to library consumers.

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
Waku core	27.74 KB (-0.47% 🔽)	555 ms (-0.47% 🔽)	1.8 s (+20.29% 🔺)	2.3 s
Waku Simple Light Node	262.91 KB (+0.01% 🔺)	5.3 s (+0.01% 🔺)	5.1 s (+8.75% 🔺)	10.4 s
ECIES encryption	29.58 KB (-0.45% 🔽)	592 ms (-0.45% 🔽)	2 s (-3.96% 🔽)	2.6 s
Symmetric encryption	29.59 KB (-0.45% 🔽)	592 ms (-0.45% 🔽)	1.9 s (+10.51% 🔺)	2.5 s
DNS discovery	110.58 KB (-0.12% 🔽)	2.3 s (-0.12% 🔽)	3.9 s (+25.5% 🔺)	6.1 s
Privacy preserving protocols	117.31 KB (0%)	2.4 s (0%)	3.4 s (+5.04% 🔺)	5.7 s
Light protocols	25.89 KB (-0.47% 🔽)	518 ms (-0.47% 🔽)	1.9 s (+20.86% 🔺)	2.4 s
History retrieval protocols	25.09 KB (-0.36% 🔽)	502 ms (-0.36% 🔽)	2 s (+46.33% 🔺)	2.5 s
Deterministic Message Hashing	5.65 KB (0%)	113 ms (0%)	576 ms (+17.22% 🔺)	689 ms

[fryorcraken]

This does not fix the whole problem. does it?

A cursor passed to a store API might still have a different pubsubtopic that the IDecoder if the developer makes a mistake and cross their wires.

[danisharora099]

This does not fix the whole problem. does it?

A cursor passed to a store API might still have a different pubsubtopic that the IDecoder if the developer makes a mistake and cross their wires.

Good point. Also added an if condition to check that the pubsub topic from Decoder should match the one in Cursor