feat(iroh-sync): Queries and "views"

[Frando]

Description

Implementation of #1667, extends #1701

With the following changes after discussions in Discord:

• Remove the notion of views, instead embed the info in the query. If the high-level concept of views makes more sense for people from an API perspective, we can restore it in the client api. However under the hood the query details are different per view, this is why here I expose a single Query struct
• Add a query builder with a typestate to only allow possible combinations
• Add an index to the redb (fs) document store to make queries that are sorted by key, or that are filtered by key but not by author, efficient. This also is what allows to do queries for the "latest only" entry per key, without allocating the full result set.

In the process I did a refactoring of the redb store to be safer to use. Especially, I moved the ouroboros self-referencing stuff into a ranges module, and encapsulated in an inner type to keep the self-referencing compilcations scoped. Also did something I had mind for a while: Add some type-safe abstractions around the range bounds constructions that are used when selecting on redb tables. All this turned out quite nice, IMO.

Also contains the changes from #1772 :

• Renames get_one to get_exact
• Add flag to get_exact whether to include empty entries or not
• Add get_one to iroh::client::Doc to get a single entry with the same query mechanisms as get_many

Open questions and tasks:

• Naming review of the query builder methods
• Integration of the query parameters in the console

Notes & open questions

Change checklist

• Self-review.
• Documentation updates if relevant.
• Tests if relevant.

[dignifiedquire]

I think you need to rebase 😅 lots of conflicts

[Frando]

I think you need to rebase 😅 lots of conflicts

yes will do, started hacking away on #1701

[dignifiedquire]

should we be duplicating the full value here? seems like we could should store a reference to the records table (not sure how to and if that is actually better..)

[Frando]

Yeah, not sure myself. It's one extra lookup vs. 156 bytes (value size) per entry.

In the most recent commit, I changed it to not duplicate the value but instead do the extra lookup.

[Frando]

I merged main and solved the conflicts from #1770.

Also added sort and desc options to doc keys console command.

This is now ready to go from my side.