feat(note-transport): add nonce to FetchNotes cursor

[kkovaacs]

Summary

Replace scalar cursors with a fixed64 nonce and sequence. Persist the nonce across restarts and return FAILED_PRECONDITION for cursors from a replaced database. Includes migration, regression tests, and updated documentation.

This is a solution to the issue where after a catastrophic event (eg. losing the note transport databse) clients get stuck receiving new notes because they're using invalid cursors. For a more detailed description please check 0xMiden/note-transport-service#97.

Changelog

[[entry]]
scope       = "note-transport"
impact      = "breaking"
description = "Changed FetchNotes cursor to a structured message containing a nonce."

[Mirko-von-Leipzig]

Nit: the doc comments are 1-line per sentence in parts here which is weird.

I think in general the docs here should be clearer e.g. avoid terms like generation and other implementation details.

We should communicate that a nonce identifies a stable sequence, and that a change in the server's nonce (e.g. if the database is reset) invalidates the current cursor, requiring a resync from scratch.

Perhaps we can also enforce the tag change == cursor invalidation, by hashing database nonce with the provided tags? That way changing tags also invalidates the cursor? If we believe this isn't expensive because we don't retain much data, then this could be a good way to enforce this API?

[kkovaacs]

Nit: the doc comments are 1-line per sentence in parts here which is weird.

I've updated the docs, I hope it's a bit better now.

Perhaps we can also enforce the tag change == cursor invalidation, by hashing database nonce with the provided tags? That way changing tags also invalidates the cursor? If we believe this isn't expensive because we don't retain much data, then this could be a good way to enforce this API?

I think that would make it pretty much impossible to implement the logic the client is implementing now when a new account (-> new tag) is added. @igamigo might have more accurate information.

[Mirko-von-Leipzig]

I think that would make it pretty much impossible to implement the logic the client is implementing now when a new account (-> new tag) is added. @igamigo might have more accurate information.

My thinking was that we could make the cursor completely opaque if we do this, and also force correct API usage.

This assumes that resyncing is "cheap" for both client and server or that adding an account/tag is a fairly rare operation.