Client code errors or manual mistakes can create transactions that are
never closed. Such transaction will work as a memory leak. Implement
timeout for transactions after which they are rolled back.

Part of #6177

@TarantoolBot document
Title: ability to set timeout for transactions was implemented
Previously transactions are never closed until commit or rollback.
Timeout for transactions was implemented after which they are rolled
back. For these purpose, in `box.begin` the optional table parameter
was added. For example if user want to start transaction with timeout
3s, he should use `box.begin({timeout = 3})`. Also was implement new
configuration option `box.cfg.txn_timeout` which determines timeout for
transactions, for which the timeout was not explicitly set. By default
this option is set to infinity (TIMEOUT_INFINITY = 365 * 100 * 86400).
Also in C API was added new function to set timeout for transaction -
'box_txn_set_timeout'.

Previously, if a yield occurs for a transaction that does not
support it, we roll back all its statements, but still process
its new statements (they will roll back with each yield). Also,
the transaction will be rolled back when a commit is attempted.
Now we stop processing any new statements right after first yield,
if transaction doesn't support it. This is done so that when we
implement timeout for transactions, the rollback of the transaction
at its expiration and at yield has the same behavior.

Part of #6177

New function box.txn_id(), which returns the id of the current transaction if
called within a transaction, nil otherwise.

Closes #6396

@TarantoolBot document
Title: new function box.txn_id()
New function in module box:  box.txn_id(), which returns the id of the current
transaction if called within a transaction, nil otherwise.

Bump debian/compat to 10 since 9 is deprecated. Bump minimal required
debhelper to 10 (except for Ubuntu Trusty and Xenial) since it is the
recommended practice for compatibility level setup.

Closes #6393

The session can be closed while kharon is travelling between tx and
iproto. If this happens, kharon shouldn't go back to iproto when it
returns to tx, even if there are pending pushes, because the connection
is going to be freed soon.

Thanks to @Gerold103 for the simple fix.

Closes #6520

This patch removes the DECIMAL truncation in LIMIT and OFFSET, because
according to the implicit casting rules, DECIMAL with digits after the
decimal point cannot be implicitly cast to INTEGER.

Closes #6485

In case user enters invalid listen address, tarantool closes previous listen
socket, but bind on invalid address fails also, so tarantool becames blind -
no listening socket at all. This patch fixed this behaviour, now tarantool
still listen old listen address.

Closes #6092

There was access to previously freed memory in case when `cbus_call`
is interrupted: `cbus_call_msg` in iproto allocates on stack, and if
`cbus_call` failed due to fiber cancelation or wake up, `cbus_call_msg`
memory is released. But function called through cbus is still work in
iproto thread and there will be an attempt to access this memory when
this function in iproto thread finished it's work. This patch rework
this behaviour, now before `cbus_call` we reset FIBER_IS_CANCELLABLE
flag, to prevent fiber cancellation or it's wake up.

Closes #6480

Bump tarantool-common dependency to use luarocks 3.
Prior to this patch, it was permitted to have
new tarantool package (version >= 2.2.1) installed with
pre-luarocks 3 tarantool-common package (version << 2.2.1).
It caused rocks install to fail.

Closes #5429

Introduced module for timestamp and interval types support.

Closes #5941

Fixes incorrect handling of variable number of arguments in box.func:call().

Closes #6405

Reasons, in short:

* It reaches end of the standard support.
* It looks barely usable with old ca-certificates due to Let's Encrypt
  certificate expire problem.
* It has problems that block updating compat level for our *.deb
  packages.

All details and links can be found in the linked issue.

Fixes #6502

There was a bug that led to dirty read after space alter. For the
simplicity sake imagine following setup:

-- space 's' is empty
tx1:begin()
tx1('s:replace{2}')
s:alter({format = format})
s:select{}

Last select returns tuple {2}, however transaction tx1 hasn't been
committed. This happens due to the fact that during alter operation we
create new space, swap all unchanged parts of old space and then delete
old space. During removal of old space we also clean-up all stories
related to it. In turn story destruction may make dirty tuple clean in
case it remains in the index. In the previous implementation there was
no removal of uncommitted tuples from corresponding indexes. So let's
rollback all changes happened to the space right in time of alter. It is
legal since DDL operation anyway aborts ALL other transactions.

Closes #6318
Closes #6263

Prior to this patch, an assertion was thrown if a tuple with an invalid
id was inserted into the _priv system space. This bug appeared only in
the debug build.

Closes #6295

Closes #4909

Implement ability to pass timeout to 'fiber:join' function.
If timeout expired, join fails with 'timed out' error.

Closes #6203

@TarantoolBot document
Title: ability to set timeout for 'fiber:join' function was implemented
Implement ability to pass timeout to 'fiber:join' function.
If timeout expired, join fails with 'timed out' error.

Add new  metrics `REQUESTS_IN_PROGRESS` and `REQUESTS_IN_STREAM_QUEUE`
to `box.stat.net`, which contain detailed statistics for iproto requests.
These metrics contains same counters as other metrics in `box.stat.net`:
current, rps and total.

Part of #6293

@TarantoolBot document
Title: detailed iproto requests statistics was implemented
Add new  metrics `REQUESTS_IN_PROGRESS` and `REQUESTS_IN_STREAM_QUEUE`
to `box.stat.net`, which contain detailed statistics for iproto requests.
These metrics contains same counters as other metrics in `box.stat.net`:
current, rps and total.
```
-- statistics for requests currently being processed in tx thread.
REQUESTS_IN_PROGRESS:
current: -- count of requests currently being processed in the tx thread
rps: -- count of requests processed by the tx thread per second
total: -- total count of requests processed by tx thread

-- statistics for requests placed in queues of streams.
REQUESTS_IN_STREAM_QUEUE:
current: -- count of requests currently waiting in queues of streams
rps: -- count of requests placed in streams queues per second
total: -- total count of requests, which was placed in queues of streams
          for all time
```

If we insert a tuple in space with an index that is being built in background,
new tuple will or will not be inserted into new index depending on the result of
lexicographical comparison with tuple which was inserted into new index last.
The problem is hash index is unordered, so background build will not work properly
if primary key is HASH index.

To avoid this, disable building index in background if primary index is hash.

Closes #5977

It's not needed now, because error marshaling is enabled automatically
if the connector supports it (IPROTO_FEATURE_ERROR_EXTENSION is set in
IPROTO_ID features).

Closes #6428

@TarantoolBot document
Title: Drop error_marshaling_enabled session setting

box.session.setting.error_marshaling_enabled was used to enable encoding
errors returned by CALL/EVAL in the extended format (as the MP_ERROR
MsgPack extension). Now, the feature is enabled automatically if the
connector supports it (sets IPROTO_FEATURE_ERROR_EXTENSION in IPROTO_ID
features).

This patch adds a new msgpack.cfg: encode_error_as_ext. Setting it makes
msgpack and msgpackffi modules encode errors as the MP_ERROR msgpack
extension. If the flag is unset, msgpack.encode behavior depends on
encode_load_metatables, encode_use_tostring, and encode_invalid_as_nil
options, see luaL_convertfield(), while msgpackffi.encode() will always
encode errors as strings. The latter needs to be fixed, but it's out of
the scope of this work and tracked separately, see #4499.

The new option is enabled by default.

Interaction with box.session.settings.error_marshaling_enabled: errors
are encoded as the MP_ERROR msgpack extension when returned via IPROTO
iff both error_marshaling_enabled and encode_error_as_ext are set.

Closes #6433

@TarantoolBot document
Title: Document msgpack.cfg.encode_error_as_ext

The new option determines how error objects (see box.error.new) are
encoded in the msgpack format:
 - If it's set, errors are encoded as the MP_ERROR msgpack extension.
   This is the default behavior.
 - If it's unset, the encoded format depends on other msgpack
   configuration options (encode_load_metatables, encode_use_tostring,
   encode_invalid_as_nil). With the otherwise default configuration,
   they are encoded as strings (see error.message).

Functions affected by the default configuration (msgpack.cfg):
 - msgpack and msgpackffi modules
 - Storing errors in tuples and spaces (box.tuple.new)
 - Returning errors from IPROTO CALL/EVAL

Whether errors are encoded as a msgpack extension or not is determined
by the serializer_opts::error_marshaling_enabled flag. Although an
instance of serizlier_opts is passed to luamp_encode(), it doesn't
propagate it to luamp_encode_extension_box(). The latter encodes an
error as a msgpack extension if the error_marshaling_enabled flag is set
in serializer_opts of the current session. This leads to a bug when
luamp_encode() is called with error_marshaling_enabled unset while the
current session has the flag set:

 1. luaL_tofield() sets field->type to MP_EXT and field->ext_type to
    MP_UNKNOWN_EXTENSION, because the error_marshaling_enabled flag is
    unset:

    https://github.com/tarantool/tarantool/blob/b0431cf8f47e9d081f6a402bc18edb1d6ad49847/src/lua/serializer.c#L548

 2. Basing on the ext_type, luamp_encode_r() skips the MP_ERROR
    swtich-case branch for the default branch and calls the
    luamp_encode_extension callback:

    https://github.com/tarantool/tarantool/blob/b0431cf8f47e9d081f6a402bc18edb1d6ad49847/src/lua/msgpack.c#L203

 3. The callback implementation (luamp_encode_extension_box()) encodes
    the error, because the error_marshaling_enabled flag is set in the
    current session settings, and returns MP_EXT:

    https://github.com/tarantool/tarantool/blob/b0431cf8f47e9d081f6a402bc18edb1d6ad49847/src/box/lua/init.c#L420

 4. luamp_encode_r() assumes that the callback didn't encode the
    extension, because it returned MP_EXT, and encodes it again as
    a string:

    https://github.com/tarantool/tarantool/blob/b0431cf8f47e9d081f6a402bc18edb1d6ad49847/src/lua/msgpack.c#L209

This results in a broken msgpack content.

To fix this bug, let's do the following:
 - luaL_tofield() now sets ext_type to MP_ERROR unconditionally,
   irrespective of serializer_opts::error_marshaling_enabled.
 - luamp_encode_r() invokes the luamp_encode_extension callback for
   a MP_ERROR field only if error_marshaling_enabled is set. If the flag
   is unset, it proceeds with converting the field to string.
 - luamp_encode_extension_box() doesn't check serializer_opts anymore.
   It doesn't need to, because it's called iff error_marshaling_enabled
   is set.
 - YAML and JSON encoders are patched to handle the MP_ERROR field type
   by appending error::errmsg to the output (they use luaL_tofield()
   internally to determine the field type so they have to handle
   MP_ERROR).

This basically disables error encoding as msgpack extension
everywhere except returning an error from a Lua CALL/EVAL, in
particular:
 - when creating a tuple with box.tuple.new(),
 - when inserting an error into a space,
 - when encoding an error with the msgpack module.

This is okay, because the functionality has always been broken anyway.
We will introduce a separate msgpack encoder option to enable encoding
errors as MP_ERROR msgpack extension.

Looking at the code links above, one is likely to wonder why error
encoding was implemented via the encode extension callback in the first
place. The lua/msgpack module knows about the MP_ERROR extension and
even partially handles it so it'd be only natural to call the error
encoder function directly, as we do with decimals and uuids.
Unfortunately, we can't do it, because the error encoder is (surprise!)
a part of the box library. I filed a ticket to move it to the core lib,
see #6432.

Closes #6431

Now net.box sends IPROTO_ID request on (re)connect to query features
supported by the server and report its own features. The version and
features reported by the server are checked against the new connection
options:

 - required_protocol_version - min version (unsigned)
 - required_protocol_features - required features (array of strings)

If the server version is older than specified or the server lacks
certain features, the connection will fail.

Features supported by the server are stored in the peer_protocol_version
and peer_protocol_features fields of a connection.

Closes #6253

@TarantoolBot document
Title: Document required_protocol_version/features net.box options

Two new options can now be passed to net.box.connect():

 - required_protocol_version: min IPROTO protocol version that must be
   supported by the server. Type: unsigned integer.
 - required_protocol_features: array of IPROTO protocol features that
   must be supported by the server. Type: array of strings.

If the server version is less than the specified or the server lacks
certain features, the connection will fail with the corresponding error.

Querying server features is implemented via the IPROTO_ID command.
Currently, there are two features defined: streams and transactions.

Irrespective of the options used, the actual version and features are
reported via peer_protocol_version and peer_protocol_features fields of
the connection. Example:

```
tarantool> require('net.box').connect(3301, {
         > required_protocol_version = 1,
         > required_protocol_features = {'transactions'},
         > })
---
- peer_protocol_version: 1
  peer_uuid: 7a8cfdbd-6bbc-4d10-99e5-cbbd06a2382f
  opts:
    required_protocol_version: 1
    required_protocol_features:
    - transactions
  peer_protocol_features:
    transactions: true
    streams: true
  schema_version: 80
  protocol: Binary
  state: active
  peer_version_id: 133632
  port: '3301'
...
```

The new request can be used by a client to let the server know about
supported IPROTO protocol features. The request body contains two
fields: IPROTO protocol version and supported IPROTO protocol features.
In reply to a IPROTO_ID request, the server sends its own protocol
version and supported features.

Currently, the actual protocol version is 1 and there are two features
defined which are always set - streams and transactions.

Part of #6253

@TarantoolBot document
Title: Document IPROTO_ID request

The new request code is 73. It takes a map in the body with the
following keys:
 - IPROTO_VERSION (0x54) - protocol version (unsigned).
 - IPROTO_FEATURES (0x55) - array of protocol feature ids (unsigned).

A client (connector) can send this request to let the server know about
the protocol version and features it supports. The server may enable or
disable certain functionality basing on the features supported by the
client. In reply to the request, the server sends an IPROTO_OK response,
in the body of which it reports its own protocol version and features
(the format of the response body is the same as the request body).
The request doesn't need authentication to pass.

Currently, the actual protocol version is 1 and there are two features
defined:
 - IPROTO_FEATURE_STREAMS - streams support (IPROTO_STREAM_ID header
   key), id = 0.
 - IPROTO_FEATURE_TRANSACTIONS - transactions support (IPROTO_BEGIN,
   IPROTO_COMMIT, IPROTO_ROLLBACK commands), id = 1.

This patch reworks approach to fiber management in Lua. Before
this patch each action that should return fiber led to new
userdata creation that was quite slow and made GC suffer. This
patch introduces new field in struct fiber to store a reference to
userdata that was created once for a fiber. It allows speedup
operations as fiber.self() and fiber.id().
Simple benchmark shows that access to fiber storage is faster in
two times, fiber.find() - 2-3 times and fiber.new/create functions
don't have any changes.

The problem is if we add a tuple to index and then fiber yield occurs (build-in-background),
replace of this tuple will change it in building index, but it will not be changed back
in case of rollback.

Closes #5958

Currently, if we delete tuple while primary index is altering in background,
a reference to removed tuple will be kept by primary index.

Closes #6290

Part of #5958

This patch fixes the comparison between DECIMAL as a left value and
DOUBLE greater than or equal to 1e38 or less than or equal to -1e38 as a
right value. Any DOUBLE value greater than or equal to 1e38 is now
greater than any DECIMAL value, and a DOUBLE value less than or equal to
-1e38 is less than any DECIMAL value. This is because our decimal cannot
contain more than 38 digits.

Closes #6376

Fixed dropping incoming messages when connection is closed or SHUT_RDWR
received and net_msg_max or readahead limit is reached. Now we don't close
connection if an error occurred while writing response, but only set a
special flag to stop further writing. Connection will be closed when we
read 0 from socket and process all requests.

Closes #6292

Currently there are several statistic metrics for iproto, which can
be obtained by using `box.stat.net`: `CONNECTIONS`, `REQUESTS`, `SENT`
and `RECEIVED`. Add new metric `STREAMS` which contain statistics for
iproto streams.

Part of #6293

@TarantoolBot document
Title: getting statistics for iproto streams was implemented
Add new  metric `STREAMS` to `box.stat.net`, which contain statistics
for iproto streams. `STREAMS` contains same counters as `CONNECTIONS`
metric in `box.stat.net`: current, rps and total. For example:
STREAMS:
  current: 0
  rps: 17980
  totat: 112623

Currently getting iproto statistics per thread is possible only
in debug mode, using `ERRINJ_IPROTO_SINGLE_THREAD_STAT` (it can be
used only in tests). This way have several disadvantages: first of
all `errinj` is not a place to get statistics, secondly user may be
interested in getting iproto statistics per thread. In this patch
`box.stat.net.thread` was implemented, it can be used for getting
same statistics as from `box.stat.net` but per thread.

Part of #6293

@TarantoolBot document
Title: getting network statistic per thread was implemented
User has possibility to run several iproto threads, but at the moment
he can get only general statistics, which combines statistics for all
threads. Now `box.stat.net.thread` has been implemented to get the same
statistics as when using `box.stat.net`, but for a thread. User can call
`box.stat.net.thread()` as a function to get general network statistics
per threads. For example for two iproto threads:
---
- - SENT:
      total: 0
      rps: 0
    CONNECTIONS:
      current: 0
      rps: 0
      total: 0
    REQUESTS:
      current: 0
      rps: 0
      total: 0
    RECEIVED:
      total: 0
      rps: 0
  - SENT:
      total: 0
      rps: 0
    CONNECTIONS:
      current: 0
      rps: 0
      total: 0
    REQUESTS:
      current: 0
      rps: 0
      total: 0
    RECEIVED:
      total: 0
      rps: 0
...

Also user can indexed it as a table by thread number. For example
`box.stat.net.thread[1]` returns network statistics for first iproto
thread:
---
- SENT:
    total: 0
    rps: 0
  CONNECTIONS:
    current: 0
    rps: 0
    total: 0
  REQUESTS:
    current: 0
    rps: 0
    total: 0
  RECEIVED:
    total: 0
    rps: 0
...

Make lbox_tuple_format_new (exported as box.internal.new_tuple_format to
Lua) reuse tuple formats. It's safe, because formats exported to Lua are
immutable. This fixes a net.box error when one creates/closes a lot of
net.box connections: a net.box connection creates a few formats for a
local version of the schema so if the garbage collector isn't invoked to
clean up after it, Tarantool can run out of format ids.

Closes #6217

This patch fixes the problem with copying an empty string in mem_copy().
Previously, because the string length was 0, an error was thrown, but
the diag was not set, which could lead to an error due to an empty diag
or to a double free.

Closes #6157
Closes #6399

In case we are updating "cluster" field in on_replace_dd_schema trigger
we do not check verifying that value corresponding to "cluster" key is
uuid. Meanwhile in contrast to other tuple_field_*() decoding functions
tuple_field_uuid() EXPECTS that passed value is type of mp_string. So
let's add extra string check to tuple_field_uuid().

Closes #6332

At the moment, when a net.box connection is closing we are cancel worker
fiber. In this case, data that was not sent is lost. In this patch connection
closing without dropping requests was implemented: before canceling fiber we
wait on conditional variable until all data will be sent.

Closes #6338

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

Closes #4717

After this patch, getting an unknown msgpack extension in SQL will throw
the correct error.

Closes #6375

Four changelog entries were fixed to resolve syntax errors.

This patch enables static and dynamic type check for functions SUBSTR(),
GROUP_CONCAT(), REPLACE(), TRIM(). All these functions afther this patch
will be able to return VARINARY value when VARBINARY arguments are given
instead of STRING arguments.

Closes #6105