Now coordinator dispatches SQL patterns with separated parameters.
It would help us to cache patterns on the segments as prepared
statements one day and skip SQL parsing.

Also we have faced a Tarantool bug

https://github.com/tarantool/tarantool/issues/7283

and made a hot fix in the Picodata fork. As a result we have also
migrated sbroad CI to our fork.

We migrate from the `decimal` crate (used decQuad from decNumber
to store the numbers) to Tarantool internal types provided by the
Rust module. The reason was to make IR numeric values easy
serializable to the query parameters (a part of the executor
refactoring).

The problem with Tarantool internal types is that the internal
decNumber representation is provided by Tarantool ABI. So we always
need Tarantool itself to use the types. It is ok for integration
tests, but for unit tests with `cargo test` it is a problem. As a
solution we have implemented some mocking infrastructure to build
a static library based on the Tarantool decNumber, MsgPuck and some
wrappers over them both to make unit tests work.

Дмитрий Кольцов authored 2 years ago and Denis Smirnov committed 2 years ago

Co-authored-by: Denis Smirnov <sd@picodata.io>

As a side effect we lost an ability to replace already existing
tuples. As a result we have detected a problem in regression tests:
concurrent distributed truncate and insert commands can execute out
of order on different segments. As a result we get "duplicate key"
errors. To deal with it, init tables and truncate them only once:
at the beginning and at the end of the test group.

After implementing cartridge sharding mock tests were mostly
useless: we didn't see how we modify SQL according to some specific
shard.

Now (in a case of the filtered buckets when we send a query to exact
shards) mock engine generates SQL for every shard. This behavior
differs from the cartridge engine that groups buckets by replicasets
first and then generated SQL for a replicaset bucket group. But the
idea of the mock engine is to detect errors but not to implement
actual Tarantool. So, lets make things simple and use this approach.

Previously we had a data sharding only on the planner side.

docs(README): state that Sbroad is an executor for `cartridge`-based cluster, because `vshard` cluster is required but not enough

Also added missed pretty_assertions to some of the tests in the
cartridge module.