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

This patch adds necessary cmake configurations for the
<evread.lua> module, so it can be used later to implement
human-readable error reporting in profile parsers.

Part of #9217

NO_DOC=LuaJIT submodule
NO_TEST=covered by the LuaJIT tests
NO_CHANGELOG=build

Current func_adapter implementation has several drawbacks. Firstly, the
interface has 21 virtual method (except for virtual destructor) which
means you need to implement all these methods if you need a new
func_adapter. Secondly, if you need to pass arguments from Lua to
func_adapter, you need to iterate over Lua stack and push the value to
func_adapter with appropriate type.

We have internal interface for calling persistent functions - port.
Let's use it for triggers too. It will allow to easily implement new
func_adapter since it will have only call method and virtual destructor.
Also, it will allow to easily call any func_adapter from Lua using
port_lua - now module trigger relies on the fact that there are only Lua
triggers. This change reduces code complexity as well - since we are
using port_c for triggers, that allows to be dumped several times, we
can create helper `event_run_triggers` which incapsulates work with
`event_trigger_iterator` and simply calls all the triggers from the
event passing the same port with arguments.

Since func_adapter is used mostly for triggers, let's make both ports
arguments optional - many triggers have no arguments and almost all
triggers ignore returned values.

Along the way, fix a possible crash when iterator passed to
transactional trigger is saved and used after the trigger is over.

NO_CHANGELOG=internal
NO_DOC=internal

The method allows to represent port contents as a list of port_c_entry.
It is handy to easily iterate over the port contents since port_c_entry
is actually a list of variants of supported by Tarantool types. It is
needed to easily process values returned from triggers.

Returned entries mustn't be destroyed since they don't own any resources.
Their lifetime is similar to the MsgPack obtained by port_get_msgpack -
it may be returned directly from the port, or it can be allocated on
fiber()->gc, so the caller is responsible for cleaning the region up.

NO_CHANGELOG=internal
NO_DOC=internal

We are going to use port_c for user-defined triggers, so we need to add
an ability to store iterator in port_c. Also, this port already allows
to be dumped several times - we should keep this invariant to call
chains of triggers using only one port.

Therefore, this commit populates port_c with new type called `iterable`.
An iterable object is an object that can create iterators - an iterator
is created on each dump. We decided that such approach is more
convenient than copying an iterator in initial state on each dump.

Iterable object and created iterator have no destructor and any
invalidation logic, so author of pushed object must think about iterator
invalidation by himself. What's about destructors, user of port_c must
ensure that the object is alive as long as the port can be dumped. When
port_c is not needed anymore, the object can be deleted by caller.
Created iterator has no destructor because we think that iterator
shouldn't own any resources - its state is allocated when the iterable
object is dumped, and the release of the state lies on the side that dumped
the object. Rationale: if you dump iterable object to Lua, the
iterator is most likely to be freed only when Lua VM will run out of
memory (GC will be called then), so Tarantool resources will be occupied
for a long time. Let's try to avoid such situation.

NO_CHANGELOG=internal
NO_DOC=internal

We are going to use ports for triggers. The problem is there is no port
implementation that meets all requirements to be used to pass arguments
to triggers from C, so let's extend existing port_c. This port is
already allows to be dumped several times - let's keep this invariant to
call chains of triggers using only one port.

Let's store trivial types directly, not packed in  MsgPack. Then, we won't
need to make a second mempool allocation to store them and we won't need
to decode them to read.

It's worth noting that port_c has two MsgPack types now - MP and
MP_OBJECT. The first now is a MsgPack packet that will be unpacked on
dump if it's possible. For example, we can pass a field of tuple, which
is a MsgPack packet, to field constraint, and it will be unpacked when
it will be dumped to Lua, so the constraint argument will have a Lua
value, not MsgPack. On the other hand, we want to dump MsgPack as a
MsgPack object sometimes. For instance, we use MsgPack object to pass
request header and body to iproto override handlers and space recovery
triggers.

NO_CHANGELOG=internal
NO_DOC=internal

Methods `get_msgpack` and `dump_msgpack` generally do the same things
except for some details (array header, type of destination buffer), so
let's factor out their core part into a separate function - it doesn't
make much sense right now, but we are going to populate port_c with new
types, and these two functions would become very similar without this
refactoring.

Along the way, let's panic in these methods when we are out of memory -
it's the approach we are taking right now in Tarantool. Corresponding
error injection is dropped as well.

NO_TEST=refactoring
NO_CHANGELOG=refactoring
NO_DOC=refactoring

For easier maintenance, let's panic when there is no memory for allocation
needed to add a value to port - that's the approach we're taking right
now in Tarantool and we don't need to check return code of `port_c_add*()`
functions because they became non-failing. Functions from C API still
return int (which is always zero actually) for backward compatibility.

NO_TEST=no behavior changes
NO_CHANGELOG=no behavior changes
NO_DOC=no behavior changes

Since we have a special mp_ctx type for mp_object, incapsulating
tuple formats and key translation, let's replace iproto_key_translation
with iproto_mp_ctx.

NO_TEST=no behavior changes
NO_CHANGELOG=internal
NO_DOC=internal

We are going to populate port_c with mp_object, which requires mp_ctx.
However, we want to have an ability to dump one port_c instance several
times, so we need to add virtual copy to mp_ctx.

It would be fair to say that copy constructor must accept `src` as a
constant object, but this approach is inconvinient in C, and such method
would be embarrassing to use in our code. So `src` is not constant in
copy constructor.

Method copy of mp_box_ctx is not implemented because it's not trivial,
it probably will require reference counting in tuple_format_map. Anyway,
it is not needed now, so that's not a problem.

Also, mp_ctx_move required dst to be default initialized. However, since
it provides semantics of move constructor, we shouldn't expect dst to be
initialized at all, since constructor is used to construct an
uninitialized object. So let's drop this requirement along the way.

NO_TEST=trivial
NO_CHANGELOG=internal
NO_DOC=internal

Since fiber lua state can be used for internal purposes, we cannot
truncate it, so we need an abitily to create port_lua with lower index
boundary. The patch populates the port with field bottom - dump will
start from this index at Lua stack.

Also, the patch modifies port_lua destructor - all unused values are
popped from lua stack now to prevent Lua stack overflow.

NO_CHANGELOG=internal
NO_DOC=internal

Since we are going to pass arguments to triggers with ports, we need to
move all functions that fire triggers to box because ports are
implemented there.

Making functions that run triggers external (similar to cord_on_yield)
leads to more circular dependencies and problems with linker - I didn't
cope with box and box_error circular dependency, so let's use core
triggers as callbacks to avoid this problem.

NO_TEST=no behavior changes
NO_CHANGELOG=no behavior changes
NO_DOC=no behavior changes

Since we are going to rewrite func_adapter to use ports for arguments
and return values, submodule port must be initialized before `box.cfg{}`
because triggers are allowed to be used before database configuration.
So let's init and free port submodule in `box_init` and `box_free`
functions instead of `box_storage_init` and `box_storage_free` -
`box_storage` is initialized on `box.cfg{}` call.

NO_TEST=no behavior changes
NO_CHANGELOG=no behavior changes
NO_DOC=no behvior changes

We are going keep existing format messages for most of existing error
codes as mentioned in more details in the previous commit. But sometimes
we want error constructor argument to be formatted and to be added to
payload differently. One example is `ER_TUPLE_FOUND` we want tuples to
be formatted as string as before in formatted string but want to add
them as `TUPLE`.

For this purpose let's use "" payload field name. In this case error
constructor argument will be used for formatted string but will not be
added to the error payload.

Follow up #9109

NO_CHANGELOG=internal
NO_DOC=internal

We are going keep existing format messages for most of existing error
codes. This way we will keep all the details in the error messages
until `compat.BOX_ERROR_SERIALIZE_VERBOSE` is switched to 'new' so
details will not disappear from logs/console output. Also we won't need
to change existing Tarantool and integration tests.

Follow up #9109

NO_CHANGELOG=internal
NO_DOC=internal