BREAKING CHANGE: rename execute_query to dispatch_query

The main reason is that we'll soon need not only a coordinator
runtime, but also a new storage runtime as well. Current names
can confuse us in future.

Also add an ability to evaluate an arbitrary eviction funtion for
the LRU cache (on the storage side we'll need it to flush prepared
statements from the Tarantool cache when our LRU cache evicts the
one).

LRU cache was moved from within the cache folder into the engine.

Router logic was moved to a separate file in the cartridge module.

picodata features enables Picodata Tarantool fork functionality
Schema enables functionality needed to operate spaces metadata

This reverts commit d9b2f822.
Cargo.lock is now included in repo, so no need to fix version to get
reproducible build

We want to get reproducible builds. Cargo.lock does exactly this.
On the start of the development we were following the rule that
"libraries does not include cargo.lock in git, binary does".
However we misinterpreted the role of Sbroad. It is built as a "cdylib"
so we should treat it as an executable and include cargo.lock

Closes #202

Closes #183

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