refactor: query filters

[DCNick3]

Description

This PR introduces a lot of changes to the query subsystem. I tried to make the changes gradually in smaller PRs, but it ended up being very intertwined =(

Summary of changes

• Queries are now split into two categories: iterable queries which return sequences of results and singular queries that return a single value. They are now fully disjoint traits stored in different Box enums, as they require very different handling.
• Query filters (aka predicates) are now typed depending on the type of the iterable query they are applied to (Restrict types of predicates applied to queries depending on the query output type (type-safe queries) #4569). Instead of a single PredicateBox there is a predicate type for each queryable type (like AccountPredicateBox), with CompountPredicate<T> providing the logical operations on top.
• A new rust DSL to construct the predicates is introduced. It is designed to look very close to how one would write an Iterator::filter closure (|obj| obj.field.inner_field.starts_with("hello")) and is inspired by diesel's DSL.
• HTTP clients and wasm code (smart contracts, triggers and executor) are now using a common query builder struct, generic over a new QueryExecutor trait
• The HTTP API is majorly revamped to pass all of the params as scale-encoded values. This simplifies the torii handler, makes it more type-safe (can't add pagination to singular query) and allows sharing more code with wasm
• All of the queries that can be implemented as filtered versions of other queries are now removed. Here's a rough google table I made to keep track of all of them: https://docs.google.com/spreadsheets/d/1Cx9cU4wLk1ZyIa3Igx0NN9azl9dfqcXXMJMLKTMxes4/edit?usp=sharing

The primary key question

Currently we have a bunch of queries that give you an object using its Primary Key (like FindAccountById). They can be implemented by filtering a basis query that returns all objects of such type (like FindAllAccounts). However, with naïve implementation (which this PR currently does) this would result in O(n) complexity instead of O(log n) that we currently have.

There is a way to do these lookups fast: just pattern-match the filter on the shape |obj| obj.id.eq(expected_id) and use the primary key index instead of linear scan. We can even use a similar approach to speed up other types of queries, if deemed necessary.

However, merging it as-is would mean that the primary queries would be slow. I can probably add the PK queries back for now, if that's unacceptable.

Future work

These are improvements I see that can be made to this PR, but I would prefer them to be implemented in separate PRs. I'll convent them to issues when this PR gets closer to getting merged.

Perf:

• the Primary Key optimization (see above, Add optimizations for primary key queries #4895)
• make queries truly lazy (put them into the query store without collecting them all in a vec); Needs investigation whether that'll actually be beneficial and some clever implementation (need to store an iterator with lifetime tied to iroha state snapshot).

Ergonomics:

• remove the client::account::all() et al, as this API doesn't provide much value compared to FindAccounts::new() and doesn't exist in smart contracts (revise query API on client #4892)
• provide helpers like client::domain::by_id, with them still relying on filtered queries
• impl Into<String> for ids (Make methods accepting ids by value generic over its referencedness #4832)
• introduce a client-like object for smart contracts to make the API more similar to that of the Rust client (Introduce a client-like object for smart contracts #4898)
• expose query types in schema for the ergonomic improvements to translate to SDKs (Expose query typings in schema #4902)
• provide an async client for query execution (Allow async execution of queries in client #4935)

Misc:

• Display representations for queries & filters (right now printing them with Debug)
• check that the iterable query continuation is executed by the same authority as the one that started it
• get rid of more singular queries (Get rid of the remaining singular queries #4933)

Linked issue

Closes #4569, #4720, #3720, #3671.

Checklist

I still have a lot of doc strings, an overview of the predicate DSL implementation and some tests to write, hence marking this PR as a draft.

• add more docs and remove all the #[warn(missing_docs)]
• add more tests of the DSL
• add a test checking the validation performed on SignedQueryCandidate
• fix client cli tests
• fix ui tests
• make CI pass

[Erigara]

Are projections smt we can introduce later?
To get rid of queries like FindAllRoleIds into smt like query_iter(FindAllRoles).with_projection(|role| role.id)

[DCNick3]

Are projections smt we can introduce later?

Yeah, adding projections in the future is possible. Would also shave off a few specialized queries we have. Although I haven't really been thinking about possible designs.

[Erigara]

However, merging it as-is would mean that the primary queries would be slow. I can probably add the PK queries back for now, if that's unacceptable.

Degradation in PK quires might introduce overhead into permission checks in the executor, so we should be careful with it.
Imo we can return PK queries for now and than gradually replace them filters after optimization will be introduced.

[Erigara]

Can you describe briefly describe idea behind new predicates?

Like i can see now that we have AstPredicate, AtomPredicate, ...

What are stages predicate go though?

[Erigara]

I like that now quires are handled more uniformly between client and wasm.

Also that now each query is coupled with specific filters is convenient as well.

[DCNick3]

@Erigara

Can you describe briefly describe idea behind new predicates?
Like i can see now that we have AstPredicate, AtomPredicate, ...
What are stages predicate go though?

I've pushed some docs, including explanations of this topic. You would probably want to take a look at query::predicate::{self, prototypes, projectors}. If I missed any of the topics or any of the explanations are bad - please let me know!

[mversic]

I think that we should get rid of singular queries. We should have queries that return multiple results but can be filtered to return just one. Would you agree?

Edit:

I see that you mention this can be done in a separate PR. I agree

[DCNick3]

I think that we should get rid of singular queries. We should have queries that return multiple results but can be filtered to return just one. Would you agree?

I've already removed all singular queries that can be implemented as a query + filter. Some of them can be removed (by introducing projections into the query system), but others, like FindExecutorDataModel for example, just don't make sense as iterable queries.