Closes #229

The name normalization in Tarantool can be a little bit confusing
because it has two different pipelines: for SQL and for YAML
configuration.
1. SQL allows us to use table and column names with a rule:
   the name in the double quotes is processed "as is" while
   a name without double quotes is transformed to the upper
   case. Here are the examples:

   select * from t .. -> "T"
   select * from T .. -> "T"
   select * from "T" .. -> "T"
   select * from "t" .. -> "t"

   So, the only way to get in Tarantool a name with lowercase
   characters is to wrap it with double quotes.
2. YAML configuration allows us to create distributed tables with
   the following naming convention: the name is always processed
   "as is". For example:

   t -> "t"
   T -> "T"

Closes #226

As a side effect some refactoring was made to deal with code
duplication in the cartridge, mock and bench engines.

As a side effect the code of explain was refactored and simplified.

1. When we build a configuration cache and face a table without
   a sharding column, simply skip this table (do not exit with
   error).
2. Make "space not found" error more debug firendly
3. Rename "broken test" to "ddl"

BREAKING CHANGE: reqiures Picodata Tarantool with a string quoting
fix (e9360c989129a755b86486c7bcd6e2d21a078e22).

We should not expose a sharding column (i.e. "bucket_id") for any
parts of the join if the user doesn't mention it explicitly in
projection. Otherwise we receive incorrect query results.

The error was produced by the assumption that (2, 1) > (1, 2) is
equivalent to (2 > 1) and (1 > 2). That assumption was incorrect,
so we don't merge AND chains for any operators other than Eq and
NotEq.

BREAKING CHANGE: dispatch_query() wraps result with a tuple of a
single element.

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.

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.