It is preparatory commit to add box/decimal.h header, which will hold
module API for decimals.

Part of #7228

NO_DOC=no user-visible changes
NO_TEST=no behavior changes
NO_CHANGELOG=no user-visible changes

Part of #6773

NO_DOC=Will be added later.
NO_CHANGELOG=Will be added later.

Part of #6773

NO_DOC=Doc-request will be added in another commit.
NO_CHANGELOG=Changelog will be added in another commit.

libuuid used to be a separate library since
de11d68a ("CMake: refactor
dependencies of internal libraries").

Unclear what was it done for. The commit says "fir unit tests".
But they perfectly fine can depend on libcore like many of them
do already.

Because of libuuid being a separate library, libcore can't use
tt_uuid, because that would be a cyclic dependency. And that won't
allow to introduce tt_uuid-dependent API in a next patch.

Hence libuuid is merged into libcore.

Needed for #5568

After this patch, DECIMAL values can be bound like any other supported
by SQL values.

Closes #4717

After this patch, uuid values can be bound like any other supported by
SQL values.

Part of #6164

This patch allows to operate on integer values in range [2^63, 2^64 - 1]
It means that:
 - One can use literals from 9223372036854775808 to 18446744073709551615
 - One can pass values from mentioned range to bindings
 - One can insert and select values from mentioned range

Support of built-in functions and operators has been introduced in
previous patches.

Closes #3810
Part of #4015

The bindings mechanism was not updated in scope of BOOLEAN static
type patch. Fixed.

This patch provides straightforward refactoring replacing enum sql_type
with enum mp_type. Note that we use msgpack format instead of field_type
since it is more suitable when dealing with NULLs.

Exported sql_bind structure, sql_bind_decode, sql_bind_column
and sql_bind routines in separate module bind.h. We need SQL
bindings in further pathes with check constraints. Also, bind
encapsulated in execute.c prevent us from implementation of a Lua
part of forthcoming box.execute().

Needed for #3691, #3505

This patch creates port_sql implementation for the port. This will
allow us to dump sql responses to obuf or to Lua. Also this patch
defines methods dump_msgpack() and destroy() of port_sql.

Part of #3505

Replace all usage of sqlite3_, sqlite, SQLite prefixes with simple sql_
All other occurrences of SQLite are substituted with SQL word.
SQL test suit is purified as well.

Currently, function sql_response_dump() puts data into an already
created map. Moving the map creation to sql_response_dump()
simplifies the code and allows us to use sql_response_dump() as
one of the port_sql methods.

Needed for #3505

All binary struct *_request are stored in xrow.h/.c
together with their decoders. The only reason why
xrow_decode_sql was implemented in execute.c was a
dependency on struct sql_bind. Now xrow_decode_sql
and struct sql_request operate only by MessagePack and
some iproto constants and are moved to their true
home.

Follow up #3828

Before this patch bind parameters were decoded in
iproto thread in an attempt to save some TX thread
time. But they were stored in an array allocated on
iproto thread memory. Lack of iproto_msg destructor
lead to leak of this array.

This patch makes sql_request store only raw undecoded
MessagePack and moves decoding to TX thread where in
a single function the parameters are decoded, applied
and freed.

There were a couple of alternatives allowing to keep
decoding in iproto thread and to move even more
decoding there, for example, parameters from
IPROTO_UPDATE:

* decode on malloc and add a virtual destructor to
  struct iproto_msg;

* decode on malloc and add a virtual destructor to
  struct cmsg. By the way, it could allow to reuse
  this destructor for struct cbus_call_msg and
  struct relay_gc_msg.

The way how is it solved by this patch has been chosen
thanks to its simplicity.

Closes #3828

This reverts commit bc9e41e9.

This is one step forward to make sql_request store raw
MessagePack.

Part of #3828

sql_request is now decoded entirely in iproto thread
in iproto_msg_decode unlike other similar requests
like CALL or UPDATE which could be decoded in iproto
too.

But iproto thread pays for this optimization with a
leak - sql_request.bind array is allocated on iproto
thread region and never freed.

A fix is to decode, apply and free bind array in tx
thread in one place: tx_process_sql. For this
sql_request should look like other requests: do not
decode arrays, do not store sync, store fields as
raw MsgPack.

First step - remove sync.

Part of #3828

To make functions in execute.h more universal we should reduce
their dependence on IPROTO. This patch removes IPROTO functions
from execute.c.

Needed for #3505

Refactored sql_request structure to store pointer to sql string
data and it's length instead of pointer to msgpack
representation.
This is required to use this structure in sql.c where the query
has a different semantics and can be obtained from stack as a C
string.

Needed for #3505.

According to documentation some JDBC functions have an ability to
return all ids that were generated in executed INSERT statement.
This patch gives a way to implement such functionality. After
this patch all ids autogenerated during VDBE execution will be
saved and returned through IPROTO.

Closes #2618

The #3255 fix was not applied to SQL after merge into
2.0. This is the fix.

The SQL execution must be separated from response encoding. At
first, only after execution the obuf to write to is known. At
second, in the future one SQL request will produce multiple
SQL responses.

Closes #3326

IPROTO_SQL_ROW_COUNT is not a top level key in an iproto response
and can be moved into a separate enum.

In the newest 1.7 the call/auth/dml_request decode the data
directly from a struct xrow_header instead of MessagePack data.
Make the same for sql_request.

obuf_alloc can not be used as a temporary buffer per sql row column,
because each column can be allocated in different slabs. It makes
impossible to allocate a port tuple from several intervals:
[col1_begin, col1_end], [col2_begin, col2_end], ...

Region has region_join method, which can realloc memory blocks from
different slabs in monolite memory area - [begin, end].
It allows to use tuple_alloc for port tuples.

Closes #2602

Review fixes.
Part of #2435.

Add iproto_execute command to get not only sql rows as the result,
but also sql meta data about each result column.

Make SQLITE_LIMIT_VARIABLE_NUMBER be static

SQLITE_LIMIT_VARIABLE_NUMBER is the run time limit of the
variable count in the query. The Tarantool doesn't support dynamic
limits for such things. Let's make this limit be enum instead
of value in the limits array (struct sqlite3.aLimit).

Part of #2285.