Bump test-run to new version with the following improvements:

- Bump luatest to 1.0.1-5-g105c69d [1]
- tap13: fix worker fail on failed TAP13 parsing [2]

[1] tarantool/test-run@ed5b623
[2] tarantool/test-run@7c1a0a7

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

Bump metrics package submodule. There are 8 new commits, but only
two of them affects Tarantool:
- Add election_leader_idle metric [1];
- test: run log capture tests on a separate server [2];
the other 6 affect documentation and CI/CD scripts of the original repo.
The latter one is required to bump luatest in test-run [3], since
otherwise metrics log capture test fails on a new version.

1. https://github.com/tarantool/metrics/commit/ba9726d9b0cdfb22aa56d852f7fdc7b0aa22756a
2. https://github.com/tarantool/metrics/commit/3370f856efd4172bf24916e66e3846eeb01550a8
3. https://github.com/tarantool/test-run/pull/426

NO_DOC=doc is a part of submodule
NO_TEST=repo runs submodule tests, no new test files are added

The failover coordinator is a service provided by Tarantool Enterprise
Edition. It is going to be released in the 3.1.0 version. Let's add the
`--failover` option into the help message and the man page.

This reverts commit af4bad43 ("main: hide --failover CLI option").

Part of tarantool/tarantool-ee#564

NO_DOC=the documentation request for the failover coordinator at whole
       will be added manually
NO_CHANGELOG=this is EE feature, no reason to highlight it in CE release
             notes

It is very easy to misplace a config option to a different level, for
example create an empty replicaset `sharding` with storage role, instead
of configuring sharding option to `storage`:
```
groups:
  g-001:
    replicasets:
      sharding:
        roles:
        - storage
      r-001:
        instances:
          i-001: {}
```

This patch adds validation that forbids creating an empty group or
replicaset. Note that a group or a replicaset could still be defined
in multiple config sources and may appear empty in one of them, the
check is performed on the merged cluster config.

Closes #9895

NO_DOC=bugfix

Before this patch, there was an inconsistency in config builder, one
could easily set options on global, replicaset and instance level, but
not on group level.

This patch adds a similar `set_group_option()` function that fixes the
inconsistency.

Part of #9895

NO_DOC=test helper update
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

Before this patch, there was no way to configure empty replicaset
with cluster helper, while this is a valid mistake we should verify.

This patch also adds verification on cluster:new() and
cluster.startup_error() to forbid passing intermediate
config representation that is return by cbuilder.new().

Part of #9895

NO_DOC=test helper update
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

If coverage workflow is triggered via submodule as a part of integration
testing, coverage reports from Tarantool are sent to coveralls as
reports from the submodule. Our fork of LuaJIT as well as Tarantool uses
Coveralls, this will avoid reporting Tarantool's coverage to LuaJIT's
namespace in Coveralls.

To avoid this misbehaviour, run the "upload report" step only when there
is no submodule to bump (specified as `inputs.submodule` [1]) as a part
of the reusable workflow.

[1]: https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#example-specifying-inputs

NO_DOC=CI
NO_TEST=CI
NO_CHANGELOG=CI

User is not allowed to execute TCL statements in on_commit and
on_rollback triggers - it is documented UB. However, this prohibition
can be easily overseen: one could, for example, try to rollback current
transaction if something is not OK in on_commit trigger. So let's check
if TCL statements are not executed in transactional triggers.

The commit introduces a new helper `txn_check_can_complete` - it is
required because there are cases when transaction cannot be continued
(txn_check_can_continue will return error) but it's allowed to try to
commit or rollback it. Example: when MVCC aborts a transaction due to
conflict, the result is not observed by user. So he cannot execute new
statements in the transaction, but we cannot forbid to try to commit
the transaction - only then the error will be observed and the
transaction will be actually completed (rolled back due to conflict).
But after the attempt to commit the transaction, we must forbid to
try to complete it again - it will lead to UB.

Along the way, the commit removes unnecessary check in function
`box_txn_rollback`.

Closes #7331

NO_DOC=bugfix

When we are going to start a new statement in transaction, we check if
current transaction can continue with a special helper. This helper
fails only when the transaction is aborted, but if the transaction is
committed, it actually cannot be continued as well because it is over.
So let's consider committed transactions as non-continuable.

Along the way, let's fix an error thrown when someone tries to access
database within on_rollback trigger - now it is reported as "Unknown
error", let's use "Transaction was rolled back" instead.

Closes #9186

NO_CHANGELOG=see next commit
NO_DOC=bugfix

The test checks that net.replicaset connection switches to the
new leader when the new leader is elected. Unfortunately the
test expects that after successful call of box.ctl.promote()
the old leader is guaranteed to be in RO state. Actually this
is incorrect: the new leader can legally rely on the quorum
with the third instance without even notifying the original
leader about new election term started, so the old leader may
remain in RW state. Since the replicaset connection updates
states of instances asynchronously it also may think (for some
time) that the old leader is the only RW instance in replicaset.

Fix it by including check of the new leader into retrying block
of the test.

Hotfix #9823

NO_CHANGELOG=fix flaky test
NO_DOC=fix flaky test

This patch introduces the call() function in the experiment.connpool
module. The function takes the name of the function to be executed,
arguments to the function to be executed, and options. Options are used
to select candidates, on one of which the provided function will be
remotely executed.

Closes #9842

@TarantoolBot document
Title: the experimental.connpool module

The experimental.connpool module contains some functions that allow you
to retrieve the names of instances from the configuration that satisfy
specified conditions, or to execute a function on one of these
instances. Additionally, this module has a function that returns the
active connection to the instance with the specified name.

Currently this module contains three functions:
1) `connect()` takes an instance name and options and returns the active
connection to the instance with the specified name. The
`connect_timeout` and `fetch_schema` options are passed directly to
`net.box.connect()`. The `wait_connected` option is also passed to
`net.box.connect()`, but here it can be `true` or `false`, numeric
values are not allowed.
2) `filter()` accepts only options as its only argument. It returns an
array of instance names that match the provided options. Currently only
two options are supported:
    a) `labels` that instances must have;
    b) `roles` that instances must have.
3) `call` takes the name of the function to execute, arguments for this
function, and options. The `labels` and `roles` options are used to
select candidates on which the function will be executed. If the
`prefer_local` option is false, `call` will try to connect to a random
candidate until a connection is established or there are no more
candidates. If the `prefer_local` option is true or nil and the instance
in which `call` is executed is one of the candidates, `call` will
attempt to connect to that instance first. Moreover, `call` has options
`timeout`, `buffer`, `on_push`, `on_push_ctx` and `is_async`, which are
passed directly to `net.box.call()`. Note that the `connection` option
works for the `net.box.call()` part. The potential maximum execution
time is `<number of candidates> * <default connect_timeout for
net.box.connect()> + connection`.

This patch introduces the filter() function in the experimental.connpool
module. The function takes options containing some constraints as the
only argument and returns an array of instance names that satisfy those
constraints.

Part of #9842

NO_DOC=will be added later

This patch introduces the experimental.connpool module and the connect()
function. This function returns the connection to the instance whose
name is specified as the first argument to connect().

Part of #9842

NO_DOC=will be added later

New option named http_version allows to set http version for each request.

Closes #9806

@TarantoolBot document
Title: `http_version` option for a set of functions in
`http.client` module.

The `http_version` option allows to set version of http in functions like
`request()`, `post()`, `get()` and etc using this curl option:
https://curl.se/libcurl/c/CURLOPT_HTTP_VERSION.html
The http_version takes one of the strings listed below or a nil value
and sets the appropriate protocol version.

List of supported values:
1) nil - works as '2-tls' by default.
2) '1.1' - sets HTTP/1.1 version.
3) '2' - sets HTTP/2 version that falls back to HTTP/1.1 if cannot be
   negotiated with the server.
4) '2-tls' - works as '2' for HTTPS and as '1.1' for plain text HTTP.
5) '2-prior-knowledge' sets HTTP/2 version without HTTP/1.1 at back.
   It requires prior knowledge that the server supports HTTP/2.

So that error details are added as error payload. Now client don't need
to parse error message to get details.

box/error.test is changed to pass checkpatch. It is reported 'bla bla'
as possibly repeated word.

Closes #9108
Closes #6166

@TarantoolBot document
Title: Provide error details through payload fields
Product: Tarantool
Since: 3.1

Now Tarantool error details are available as payload fields (which
in turn can be accessed as error object fields). For example:

```
tarantool> e = box.error.new(box.error.SPACE_EXISTS, 'some space')
tarantool> e.message
---
- Space 'some space' already exists
...
tarantool> e.space
---
- some space
...
```

One can introspect the details using `error:unpack()`:

tarantool> e:unpack()
---
- space: some space
  code: 10
  base_type: ClientError
  type: ClientError
  message: Space 'some space' already exists
  trace:
  - file: '[string "e = box.error.new(box.error.SPACE_EXISTS, ''so..."]'
    line: 1
...

Actually error is already set and is more precise.

Part of #9111

NO_CHANGELOG=minor
NO_DOC=minor

Part of #9111

NO_CHANGELOG=internal
NO_DOC=internal

New commits:

* matras: increase max capacity from 2^31 to 2^32 blocks
* matras: fix compilation on macOS

Closes #9864

NO_TEST=small submodule bump
NO_DOC=I will update https://github.com/tarantool/doc/issues/3816

This is the maximum possible capacity of a hash table with 32-bit record
identifiers and 8-element `LIGHT_GROW_INCREMENT`.

Needed for #9864

NO_DOC=see next commit
NO_CHANGELOG=see next commit

This function contains a bitwise optimization that returns wrong result
when table size is greater than 2^31. E.g., if table size is 0xB0000000
and hash is 0, it returns 0x80000000 instead of 0. Fix it.

Needed for #9864

NO_DOC=see next commit
NO_CHANGELOG=see next commit

That's a MVP so only part of the design document is implemented.
Only `watch_leader` method is implemented.

Watch leader is a net.box-like subscription that receives events
only from known leader. If the leader is changed - there's a
short-time probability to receive a notification from the previous
one, but there's a guarantee that once a new leader becomes known
for the net.replicaset - a new update with the new leader will
be called. While the leader is not known (no or more than one RW
instance is known) - the subscription callback is not called.

The usage is quite simple:
```
local net_replicaset = require('internal.net.replicaset')
local rs = net_replicaset.connect(replicaset_name)

-- Define event handling function.
local function func(key, value, instance_name)
    ...
end

-- Watch some_key.
local watcher = rs:watch_leader(some_key, func)

-- Stop watch.
watcher:unregister()
```

Closes #9823

NO_DOC=internal
NO_CHANGELOG=internal

This module is designed for simple net.box-like access to a
replicaset. Internally the module holds a connection to each
replica of the replicaset and subscribes to ro/rw status of
each replica. That allows to decide which instance can execute
ro/rw/leader request.

That's a MVP so only part of the design document is implemented.
Only `call_leader` method is implemented.
No additional options of connection are implemented (except those
which are accepted by net.box.connect).
Having that the implementation is in internal namespace.

The common usage is quite simple:

```
local net_replicaset = require('internal.net.replicaset')

local opts = {
    name = <optional replicaset name>
    instances = {
        [<instance_name>] = {
            endpoint = <URI to connect to, including credentials>,
            reconnect_timeout = <..> -- optional reconnect timeout.
        }
    },
    reconnect_timeout = <..> -- optional default for all instances.
}
local rs = net_replicaset.connect(opts)

-- this method is similar to net.box.call but is called on leader.
-- NO_WRITEABLE and MORE_THAN_ONE_WRITEABLE may be thrown.
-- Only two options are supported now - timeout and is_async.
local info = rs:call_leader(func_name, args, opts)

-- also similar to net.box.
rs:close()
```

If cluster config 3.0 is used then connect by name can be used:
```
-- options now has only reconnect_timeout as described above.
-- REPLICASET_NOT_FOUND error may be thrown.
local rs = net_replicaset.connect(replicaset_name, options)
```

Part of #9823

NO_DOC=internal
NO_CHANGELOG=internal

box.error creates a ClientError unless custom type is provided.
There are two forms of ClientError creation:
* box.error(code, ...)
* box.error({code = code, ...})
The first form generates an error with reason that is constructed
from internal error description, and this is good.
The second one can use reason or message explicily provided in
argument table, but if none is provided generates an empty message.
That differs for the first behavior and hampers generation of
ClientError creation from lua.

This patch fixes that and uses internal error description for
ClientError if the message was not provided explicitly.

Closes #9876

NO_CHANGELOG=was not released yet
NO_DOC=bugfix

This patch introduces the instance_uri() method for the config module.
This method returns the URI of the specified instance from the config.

Needed for #9842

@TarantoolBot document
Title: instance_uri() method for config module

The configuration module's `instance_uri()` method returns the URI of
the instance that is used to create a replicaset or sharding cluster.
This method takes two arguments:
1) `peer` or null to return the URI that is used to create the
   replicaset, or `sharding` to return the URI that is used to create
   the sharding cluster;
2) `options`, which only support `options.instance`, to specify the
   instance whose URI should be returned; by default, the URI of the
   instance on which the function is executed is returned.

Currently, the connection state is updated after calling triggers. However,
the triggers can, in turn, cause a new state change. The state will be
updated the state in the wrong order, and the original state change will
overwrite the state change from the trigger. To fix this, let's update the
connection state before calling any triggers.

Closes #9827

NO_DOC=<bugfix>

For the `on_connect` trigger, if the trigger execution fails and an
exception happens, the connection is terminated and its state changes to
'error'. It allows the following filtering semantic: the client checked
some condition from the trigger and decided that the connection does not
suite him — the exception is thrown to indicate that the connection should
be terminated.

Currently, the `on_schema_reload` trigger behaves the same way. However,
filtering a connection from the `on_schema_reload` trigger or waiting for a
schema update does not seem has neither a reasonable semantic, nor a valid
use case. Let's make the `on_schema_reload` trigger behave the same way as
the `on_disconnect` trigger, i.e, log the exception, but otherwise ignore
it.

Closes #9679

@TarantoolBot document
Title: `on_schema_reload` trigger of `net.box` connections behaviour update
Product: Tarantool
Since: 3.1
Root documents: https://www.tarantool.io/en/doc/latest/reference/reference_lua/net_box/#lua-function.conn.on_schema_reload

When an error is thrown from the `on_schema_reload` trigger, it now behaves
the same way as the `on_disconnect` trigger [^1]:
> If the trigger function causes an error, the error is logged but
otherwise is ignored.

[^1]: https://www.tarantool.io/en/doc/latest/reference/reference_lua/net_box/#lua-function.conn.on_disconnect

According to the documentation [1]:
> If the trigger function causes an error, the error is logged but
otherwise is ignored.

However, currently, the `on_disconnect` trigger behaves the same way as the
`on_connect` trigger, i.e., the connection is terminated and its state
changes to 'error'. Let's fix this inconsistency and log errors from the
`on_disconnect` trigger, but otherwise ignore them.

Closes #9677
Closes #9797

NO_DOC=<bugfix>

1. https://www.tarantool.io/en/doc/latest/reference/reference_lua/net_box/#lua-function.conn.on_disconnect

These options configure how often a state information is updated by the
failover coordinator in a remote state storage and how fast a transient
state is expired.

The new options are named as follows.

* `failover.stateboard.renew_interval`
* `failover.stateboard.keepalive_interval`

Part of https://github.com/tarantool/tarantool-ee/issues/564

NO_DOC=to be added separately
NO_CHANGELOG=Enterprise Edition feature, no new behavior in the
             Community Edition

It has been decided to drop required devx team review for tests.

NO_DOC=codeowners
NO_TEST=codeowners
NO_CHANGELOG=codeowners

This patch changes iproto listen URI setting in default-config.yaml from
`localhost:3301` to `0.0.0.0:3301`. Without this change, it's impossible
to start container and use a popular way for port publishing:

    $ docker run -p 3301:3301 --rm -d tarantool/tarantool
    $ tt connect 127.0.0.1:3301
        Connecting to the instance...
        failed to run interactive console: failed to create new console:
        failed to connect: failed to get protocol:failed to read
        Tarantool greeting: EOF

NO_DOC=docker
NO_TEST=docker
NO_CHANGELOG=docker

It is recommended for modern Tarantool based applications to use a
startup flow with `config.yaml` instead of starting of a Lua script.

Adjusted container/application/instance names to be consistent across
examples.

* container: `app-instance-001`
* application: `app`
* instance: `instance-001`

NO_DOC=it is a documentation change itself
NO_CHANGELOG=no code is changed
NO_TEST=see NO_CHANGELOG

Header "unit.h" contains `ok` and `is` macros used to check test cases.
The problem is such simple names can be used in C++ STL library headers
(it's OK because such short names can be hidden in a namespace), so when
including, for example, header "vector" after "unit.h", build can fail
because function declaration or definition in the C++ header will turn
into a macro invocation. I faced this problem building Tarantool on
MacOS with SDK of 14.4 version.

NO_TEST=fix build
NO_CHANGELOG=fix build
NO_DOC=fix build

This patch adds the Docker image build routine as a part of the release
pipeline.

A word about image tags.

For example, if a release tag is 3.1.0, the resulting Docker image will
be pushed to Docker Hub with the following tags: 3.1.0, 3.1, 3.
If a release tag is 3.1.0-alpha1, the resulting Docker image will be
pushed to Docker Hub with one tag: 3.1.0-alpha1.
Same for 3.1.0-beta1 or 3.1.0-rc1 tag.

Closes #9596

NO_DOC=cd
NO_TEST=cd
NO_CHANGELOG=cd

This patch brings a base toolset for building official Docker images for
Tarantool 3.0+ version.

Toolset components:

1. Dockerfile for building Docker images (based on Ubuntu 22.04)
2. Docker entrypoint script (docker-entrypoint.sh)
3. Default Tarantool config (default-config.yaml)
4. Auxiliary tools for checking Tarantool instance status and connecting
   to admin console
5. Example of a basic Tarantool cluster that can be started via Docker
   Compose (a tool for running multi-container applications)

Part of #9596

NO_DOC=docker
NO_TEST=docker
NO_CHANGELOG=docker

Currently, the code which tries to retrieve the __autocomplete metamethod
for cdata (cf644abd) is not exception safe: an exception can be thrown from
the __index metamethod. In order to make it exception-safe and not
overcomplicate the code, let's add a Lua wrapper for table indexation, so
we can call it from C using `lua_pcall`.

Closes #9828

NO_CHANGELOG=<not released>
NO_DOC=<bugfix>

Currently, exclude_null option doesn't affect functional indexes at all.
It seems that we just forgot to check if tuple should be inserted to the
index - the patch simply adds missing check in replace and build_next
methods of functional memtx_tree index.

Closes #9732

NO_DOC=bugfix

In order to prevent the garbage collection of the discarded connection,
asynchronous requests must reference the connection object. We must
reference the connection object rather than the transport object, because
our garbage collection hook is attached to the former.

Closes #9629

NO_DOC=<bugfix>

Closes #9863

@TarantoolBot document
Title: Document key validation and comparison `key_def` module functions

The following new functions were introduced to the `key_def` Lua module:

 - `key_def:validate_key(key)`: validates a key against a key definition
   object. Raises an exception if the key doesn't match. Returns nothing
   on success. See also `box_key_def_validate_key` C API function.

 - `key_def:validate_full_key(key)`: validates a full key against a key
   definition object. Raises an exception if the key doesn't match.
   Returns nothing on success. See also `box_key_def_validate_full_key`
   C API function.

 - `key_def:validate_tuple(tuple)`: validates a tuple against a key
   definition object. Raises an exception if the tuple doesn't match.
   Returns nothing on success. See also `box_key_def_validate_tuple`
   C API function.

 - `key_def:compare_keys(key_a, key_b)`: compares two keys according to
   a key definition object. Raises an exception if any of the given key
   doesn't match the key definition. On success, returns a value <0 if
   `key_a` parts are less than `key_b` parts, 0 if equal, >0 if greater.

Most of times the instances are already in the `'running'` status after
`cluster:start()`. However, sometimes an instance is not connected yet
to a majority of peers of its replicaset and has the `'orphan'` status.

A test unlikely assumes this situation, because it is rare. Let's wait
for the `'running'` status by default to stay on the safe side.

The new option `wait_until_running` (default is `true`) allows to opt
out from this behavior. It is set to `false` if `wait_until_ready` is
`false`.

This change improves stability of
`config-luatest/anonymous_replica_test.lua`.

Note: `wait_until_ready` waits until `config:info().status` will be
`'ready'` or `'check_warnings'` for all the instances of the cluster.

Next, `wait_until_running` on a replicaset bootstrap waits until all the
instances successfully connect to a majority of peers (see the
`replication.bootstrap_strategy` option for details).

NO_DOC=testing helper change
NO_CHANGELOG=see NO_DOC
NO_TEST=no code is added to tarantool itself

The option was handled incorrectly in some cases.

Before this commit the behavior was the following.

| Code                                      | Waits? | Is it correct? |
| ----------------------------------------- | ------ | -------------- |
| cluster:start()                           | Yes    | Yes            |
| cluster:start({wait_until_ready = true})  | Yes    | Yes            |
| cluster:start({wait_until_ready = false}) | No     | Yes            |
| cluster:start({})                         | No     | !! No !!       |

Now it is the following.

| Code                                      | Waits? | Is it correct? |
| ----------------------------------------- | ------ | -------------- |
| cluster:start()                           | Yes    | Yes            |
| cluster:start({wait_until_ready = true})  | Yes    | Yes            |
| cluster:start({wait_until_ready = false}) | No     | Yes            |
| cluster:start({})                         | Yes    | !! Yes !!      |

There are no tests affected by this problem, but it worth to fix it just
in case.

NO_DOC=testing helper change
NO_CHANGELOG=see NO_DOC
NO_TEST=no code is added to tarantool itself