chore: protocol implementations in @waku/core should be as unopinionated as possible

[danisharora099]

This is a change request

Problem

Our protocol implementations exist is @waku/core, and offer opinions on the usage such as:

• using multiple peers
• message dedeplication (for filter)

These opinions are assumptions we have made, and they sit close with the code for the protocol's purest implementation.
Problems with having a general SDK-like functionalities with protocol implementation:

• increases complexity by trying to have a great API while being bound by protocol definition
• mixed abstraction level. Protocol implementation is one level. Using protocols in a ways that increase reliability, reduces bandwidth usage etc are one level above
• makes the code less forkable and readable: 99% developers are not expected to ever touch core protocol implementation. But 80/20 rules says 20% of developers will fork or inspires themselves from general SDK to do their own custom usage of the protocols.
• finally, the protocol implementation should be simple and straightforward for readability and comparisons with the specs. Sebago avoid mixing abstraction levels.

Proposed Solutions

It would be a better approach to decouple opinions as much as possible from the protocol implementation, thus keeping it as close to pure, while introducing opinions within @waku/sdk.

This also allows us flexibility in terms of the different APIs we can provide for each protocol.

Acceptance Criteria

• Light Push: chore(lightpush)!: move protocol implementation opinions to @waku/sdk #1887
• Filter: chore(lightpush)!: move protocol implementation to @waku/sdk (1/n) #1964
• Store: chore(store)!: move protocol implementation opinions to @waku/sdk #1913

Notes

• part of the [Epic: js-waku] Reliability Protocol for Resource-Restricted Clients pm#143
• original thread by @fryorcraken: chore!: remove @waku/message-hash and use @waku/core #1810 (comment)