feat: add new message_hash column to the archive protocol

[Ivansete-status]

Problem

We have the id column in sqlite and postgres databases that is not unique.

Suggested solution (defined by @jm-clius)

Create a unique field, message_hash, which will be computed following RFC: https://rfc.vac.dev/spec/14/#deterministic-message-hashing.
The message_hash will become the PRIMARY KEY.
This should also be how the CURSOR gets computed when doing a database lookup. So querying for the next page will become much simpler - find the PRIMARY KEY that matches the CURSOR and query from that point
Drop the current id field from the current databases schemas.

Acceptance criteria

• The message_hash attribute should be present SQLite.
• The message_hash attribute should be present Postgres.
• The current id column should be ignored and removed from the database schema.
• Store protocol behaves well and pagination works well.

Epic

waku-org/pm#57

CC: @chair28980 @fryorcraken

[ABresting]

achieved

• worked on the current issue-related PRs this week, launched initial PR already, others lined up.
• finalized all remaining tasks associated with the retention policy, including infra-testing.

next

• (short-term) aim to finalize the current issue by the end of next week.
• (long-term) continuing focus on developing the sync mechanism for archive clients.

blocker

• NA.

[ABresting]

achieved

• worked on the current issue-related PRs this week, and refactored PRs based on components.
• worked on pagination in the light of new attribute

next

• PRs are lined up but linearly dependent so one at a time
• migration of new attribute

blocking

• not exactly blocking but awaiting reviews.

[ABresting]

Weekly Update

• achieved: On SQLite's schema transition (i.e. this PR) to messageHash feature complete PR posted (awaiting reviews), Gained insight into the connection and interplay between the store and archive components, and how they may be leveraged into making a sync protocol. Small stuff - bug fix on the jsWaku which was this PR dependent (that too was time-consuming since my first time interacting with JS code of waku), PR on vacuum on time-based retention policy, thought through the nitty gritty details of node based roles and incentives.

• next:

  • The sync protocol formulation totally based on the messages sync without any external factors into POV
  • Review PostgreSQL PRs by Ivan to gain more knowledge on the storage/archive feature.

[ABresting]

Weekly Update

• achieved: PR to support SQLite code to support messageHash attribute without interrupting the existing cursor-related functionality, id field stays for now. Skelton for sync in progress.

• next:

  • finalize the SQLite messageHash attribute and add a research page about it.
  • start a research page about the sync mechanism for nWaku, doing request/reply a PoC on the same.

[ABresting]

Weekly Update

• achieved: PRs and research issues related to messageHash and vacuum, pending code reviews.

• next:

  • finalizing the sync documents ranging from basic sync communication to sync databases.

[ABresting]

Weekly Update

• achieved: PRs on various issues and advanced research on Prolly trees use cases for Wakunode, investigated how Gossiplog sits outside of our priorities now.

• next: solidify the Prolly trees approach for sync based on different criteria/filters, fix some database code issues/feat.

[ABresting]

closing this issue since all tasks seem to be done now.