Previosly we had a very complicated logic for INSERT operator:
we always generated a motion node under INSERT and generated
bucket_id with a special motion command in this virtual table.
As a side effect we made motions even for those INSERTs that was
possible to execute locally.

Another problem was caused by the column type derivation in
INSERT .. VALUES .. expressions. If any column in the first row
contained NULL it confuses Tarantool and it returns scalar (or
even boolean!) type instead. And there is no projection type cast
in Tarantool's insertion. As a result we often had type mismatch
errors in INSERT .. VALUES .. queries.

The solution is to rewrite this weird logic from the scratch.
Now we rewrite the tree somehow like this:

insert into t1 (a, b) values (1, 2)

=>

insert into t1 (a, b, bucket_id)
select
  COL_1,
  COL_2,
  bucket_id(
    coalesce(cast(COL_2 as string), '')
    || coalesce(cast(COL_1 as string), '')
  )
from (
  select
    cast(COLUMN_1 as integer) as COL_1,
    cast(COLUMN_2 as unsigned) as COL_2
  from (values (1, 2))
)

- added count, sum aggregates, which can be used in queries with group by

currently we mean expression with arithmetic, bool and
unary operations by arbitrary expr

deploy: remove shell tag from deploy-luarocks job to run commands inside sbroad-builder instead of runner shell envrironment

Distribution setter is one of the most confusing and wired parts
of the code. One day I'll rewrite it in a more clear way (but not
today, sorry). But here is a small refactoring to make the parent
to child column mapping logic more clear in the code.

previously we suggested that operand of arithmetic expression is column.
it allows use alias (a as a1 + b as b2). ofcourse operand must be value
(a), while alias usage must be available for expression (a + b as sum)

we need to support arbitrary expressions consisting of logical, comparison and arithmetic operations and as sub-expression of aggregates. previously we added arithmetic exprs to selection ans join. this commit supports arithmetic (and only arithmetic) as a part of projection

When we gathered SQs we traversed only a subset of relational
nodes in `rel_iter`, because in `rel_iter` we didn't go into
children that are located in `filter` or `condition`. Now we
traverse all relational nodes in the plan.

Now if the subplan has Buckets::All and have Segmented vtables,
then we will filter vtables

We had a problem with the queries like:

select * from t1 where (a, b) in (select c, d from ...)

The root of the problem was that in a case of multiple references
to the subquery ((a, b) in (ref_c_sq, ref_d_sq)) we tried to bind
parameters multiple times that caused subtraction overflow and UB.
As a fix we stop binding parameters more than once.

Co-authored-by: ms.evilhat <ms.evilhat@gmail.com>

Remove redundant transaction start from the open telemetry's spans
in the code. There is no sense in it at the moment (seems like it
was added while prototyping tarantool space as a storage for the
per-fiber traces... but we gave this idea up and switched to the
custom Rust implementation). But if we start a transaction manually
and call sbroad execute() method, we end up with transaction already
started error. So, remove the transaction start wrappers and make
nested transactions work.

The configuration cache is a part of the executor's runtime.
Previously, quech query was holding a immutable borrow of the
runtime, while cache invalidation tried to get a mutable borrow
(apply_config). As a result, the cache invalidation always failed
to mutably borrow the runtime.
Current commit fixes the issue by wrapping the configuration in
a reference cell. As a result, apply_config now immutably borrows
the runtime and don't fail on this step.