We should not panic if we try to clear the configuration while
holding a mutable borrow on a runtime.

Previously we didn't take into account the fact, that prepared
statements act much alike OS descriptors. Though their internal
representation is located in the instance-wide memory of Tarantool,
we need to call "prepare" method to make its id from the global
cache for every new session. If the statement was not found in the
cache, then "prepare" compiles it and stores back to the cache.

BREAKING_CHANGE: sbroad works only with a current version of tarantool

Separate testing steps into lint, unit, integration and bench.

Previously we failed to deserialize decimal

BREAKING CHANGE: now we need sbroad library on the storages as well

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.