feat: add checks on table columns creation and insertion, add check on parameters number, add support of is_nullable metadata

When reading from multiple storages it is
possible that some requests will execute faster
than the others. And it could lead to wrong
results when vhard moved the buckets between
nodes.

For example: we execute `select * from t`
on storage 1 and get the results. Vshard
moves the data from storage 1 to stroage 2,
and then we execute `select * from t` and in
result we get the data (that moved) twice.

This commit fixes it by using vshard's
storage ref api. Now multi-node read requests
first create the ref on each node which
blocks vshard rebalancing. Then we call
our stored procedure and remove the ref.

Maksim Kaitmazian authored 1 year ago and Denis Smirnov committed 1 year ago

Protocol has been moved to a separate repository called pgproto,
so there is no need to store it here anymore.

- add support for new dml operator update
- subqueries are not allowed in update
expression.
- primary key columns can't be updated.
- update as other dml operations is
not atomic: it may fail on some
storages and succeed on others.

Picodata was bumped to rust 1.71.0, so sbroad as its submodule can
finally update the rust version as well.

1. Implement an improved version of PostOrder tree traversal that
   puts nodes into the result vector only if they apply the filter.
2. Avoid string allocation caused by `ok_or` instead of the
   `ok_or_else`.
3. Remove dead code.

Stored procedures creation with "box.schema.func.create" is essentially
an insert into a system space "_func". An attempt to call that API on
a replica (which usually is a RO instance) will result
in failure in role initialization.

Alexander Tolstoy authored 1 year ago and Denis Smirnov committed 1 year ago

Also fix UnionAll and Except references.

BREAKING CHANGE!: local motion now means local materialization
of results on the storage without bucket calculation. The old
logic of "do nothing" was moved into none motion.

Implement delete SQL operator. It is always executed locally as we
delete already existing tuples and never change tuple buckets.
We reinvent the logic of the local motion policy (see the desclamer
in this commit) and materialize the primary keys from projection on
the storage. Then they are removed from the space via space API in
a single local transaction.

We need this information to perform delete and update operations
using space API in future.

Option sql_vdbe_max_steps stops long running
queries from blocking tx thread or queries that 
use too much memory during local execution. 

Each sql query is compiled into VDBE opcodes on storages. This
parameter sets max number of opcodes that VDBE
can execute.

Example: `select * from t option(sql_vdbe_max_steps=1000)`

Option vtable_max_rows limits the maximum number of rows in
virtual table. This limit is checked on storages before returning
intermediate results and on routers when receiving results from
storages.

Example: `select * from t option(vtable_max_rows=1000)`