See the documentation request below for details about the feature.

The template variables are substituted in three different places.

* On deducing configuration of the current instance from the cluster
  configuration.
* On calculation of URIs of replicaset peers to form
  `box.cfg({replication = <...>})` value.
* On calculation of URIs of all cluster members for generation of
  `vshard.{router,storage}.cfg()` configuration.

That's why we need a lot of testing code around this small feature.

Part of #8862

@TarantoolBot document
Title: config: support {{ replicaset_name }} and {{ group_name }}

The declarative configuration supports `{{ instance_name }}` template
variable from the beginning.

Now, two more ones were added: `{{ replicaset_name }}` and
`{{ group_name }}`.

All the template variables are set according to the
instance/replicaset/group topology from the given configuration.

Example:

NO_WRAP
```yaml
console:
  socket: '{{ group_name }}/{{ replicaset_name }}/{{ instance_name }}.admin'

groups:
  g:
    replicasets:
      r:
        instances:
          i: {}
```
NO_WRAP

The admin console will be at `g/r/i.admin` for instance `i`.

Follows up commit d5c874e1 ("main: rewrite help message").

Thanks to Mergen Imeev (@ImeevMA) for pointing it out!

Part of #8862

NO_DOC=The documentation request is present in d5c874e1.
NO_CHANGELOG=same as NO_DOC

This commit aims several goals.

First, we're going to recommend `tt` as a tool to run and manage
tarantool instances. The tool is going to replace `tarantoolctl` and it
seems valuable to sync recipes across different parts of the
documentation (including this help message).

Second, the action options and modifier options are separated now. At
least one action option should be specified. I hope, it is more obvious
from the help message now.

Third, single line descriptions are replaced with a bit more extended
ones to give a user basic context to understand an influence of an
option.

Updated the man page accordingly: synchronized the options, removed
`tarantoolctl`.

Part of #8862

NO_TEST=the help message is not an API for a developer
NO_CHANGELOG=nothing new here, just better wording here and there

@TarantoolBot document
Title: Update CLI options documentation

https://www.tarantool.io/en/doc/latest/reference/configuration/#command-options
seems to need an update. See the linked commit for details and updated
`tarantool --help` message.

Prior to this patch, there were many possible code execution options
that were not covered by tests. After this commit, any assert(false)
inside box_wait_limbo_acked cause a crash.

Closes #7318

NO_DOC=test
NO_CHANGELOG=test

Though the range of values of the number being converted to string in the
tuple format map test never exceeds 10, GCC 12 issues warnings about the
size of the buffer to which the string version of the number is written:

NO_WRAP
```
test/unit/tuple_format_map.c:256:53: error: ‘%zu’ directive output may be truncated writing between 1 and 19 bytes into a region of size 4 [-Werror=format-
truncation=]
  256 |                 snprintf(name, lengthof(name), "test%zu", i);
      |                                                     ^~~
test/unit/tuple_format_map.c:256:48: note: directive argument in the range [0, 9223372036854775807]
  256 |                 snprintf(name, lengthof(name), "test%zu", i);
      |                                                ^~~~~~~~~
test/unit/tuple_format_map.c:256:17: note: ‘snprintf’ output between 6 and 24 bytes into a destination of size 8
  256 |                 snprintf(name, lengthof(name), "test%zu", i);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
NO_WRAP

Let's make GCC happy and increase all the buffer sizes to 32.

NO_CHANGELOG=<build fix>
NO_DOC=<build fix>
NO_TEST=<build fix>

Closes #9321

NO_DOC=gdb extension
NO_TEST=gdb extension
NO_CHANGELOG=gdb extension

Closes #8054

@TarantoolBot document
Title: Document Lua helpers for encoding/decoding IPROTO packets

The following new constants and functions were added to the `box.iproto`
namespace:

 - `GREETING_SIZE`: Size of a Tarantool greeting message

 - `GREETING_PROTOCOL_LEN_MAX`: Max length of a protocol string that can
   be encoded in a Tarantool greeting message.

 - `GREETING_SALT_LEN_MAX`: Max length of a salt string that can be
   encoded in a Tarantool greeting message.

 - `box.iproto.encode_greeting({version = x, uuid = x, salt = x})`:
   Encodes a Tarantool greeting message. Takes a table. Returns a
   string. Raises on error. The protocol is set to "Binary" (IPROTO).

 - `box.iproto.decode_greeting(string)`: Decodes a Tarantool greeting
   message. Takes a string. Returns a table with the following fields:
   `protocol`, `version`, `uuid`, `salt`. Raises on error. The input
   string must be exactly `GREETING_SIZE` bytes long.

 - `box.iproto.encode_packet(header[, body])`: Encodes an IPROTO packet.
   Takes a packet header and optionally a body given as a table or a
   string. A table argument will be encoded in MsgPack. A string
   argument will be copied as is (it's supposed to contain valid MsgPack
   but it isn't enforced). Returns a string. Raises on error.

 - `box.iproto.decode_packet(string[, pos])`: Decodes an IPROTO packet.
   Takes a string containing one or more encoded IPROTO packets and
   optionally a position in the string to start decoding from. If the
   position is omitted, the function will start decoding from the
   beginning of the string. On success returns the decoded packet
   header, body, and the position in the string where decoding stopped.
   Both header and body are returned as `msgpack.object`. The body may
   be absent (set to nil). If the input is truncated, returns nil and
   the min number of bytes required to decode the packet. On failure,
   raises an error.

For examples, see [`test/app-luatest/iproto_encoder_test.lua`][1].

[1]: https://github.com/tarantool/tarantool/blob/master/test/app-luatest/iproto_encoder_test.lua

This patch add second lookup for constraint name in the DROP CONSTRAINT
statement.

Part of #4467

@TarantoolBot document
Title: Second lookup for names in SQL

Since all names are now case sensitive, a second lookup is now supported
to maintain backward compatibility. A second lookup by name will be
performed if the object was not found by name in the first lookup and if
the name is not enclosed in double quotation marks. The name for the
second lookup is normalized using old rules.

This patch add second lookup for index name in the following cases:
- index in INDEXED BY clause;
- index in DROP INDEX statement;
- index in PRAGMA statement.

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

This patch adds second lookup for function names in expressions.

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

This patch add second lookup for column name in the following cases:
- columns in tuple foreign key creation clause;
- columns in field foreign key creation clause;
- columns in primary key creation clause;
- columns in unique constraint creation clause;
- columns in expressions;
- columns in UPDATE TABLE statement;
- columns in INSERT INTO statement;
- columns in CREATE INDEX statement;

Also, second lookup for table name in expressions also now supported.

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

This patch add second lookup for space name in the following cases:
- foreign table in tuple foreign key creation clause;
- foreign table in field foreign key creation clause;
- table in DROP TABLE statement;
- view in DROP VIEW statement;
- table in SELECT FROM statement;
- table in DELETE FROM statement;
- table in TRUNCATE TABLE statement;
- table in UPDATE TABLE statement;
- table in INSERT INTO statement;
- table in CREATE INDEX statement;
- table in DROP INDEX statement;
- table in PRAGMA statement;
- table in SHOW CREATE TABLE statement;
- table in CREATE TRIGGER statement;
- table in ALTER TABLE statements;

Table names in expressions will be supported in subsequent commits.

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

This patch introduces a second lookup for the savepoint name in the
"RELEASE savepoint_name" and "ROLLBACK TO savepoint_name" statements.

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

This patch makes identifiers in SQL case sensitive. Prior to this patch,
these identifiers were normalized unless they were enclosed in double
quotes.

Part of #4467

NO_DOC=will be added later
NO_CHANGELOG=will be added later

This patch introduces the sql_coll_id_by_expr() function. This function
is used to search for a collation based on a given expression.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch introduces the sql_coll_id_by_token() function. This function
is used to search for a collation based on a given token.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch introduces the sql_fieldno_by_item() function. This function
is used to search for a space field based on a given element of the
struct ExprList.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch introduces the sql_fieldno_by_expr() function. This function
is used to search for a space field based on a given expression.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch introduces the sql_fieldno_by_id() function. This function is
used to search for a space field based on a given element of the
struct IdList.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch introduces the sql_index_id_by_src() function. This function
is used to search for an index based on a given element of the
struct SrcList.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch introduces the sql_space_by_src() function. This function is
used to search for a space based on a given element of the
struct SrcList. The main purpose of this function is to introduce a
second lookup for spaces, so this function is not used where a second
lookup is not required.

Needed for #4467

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

Before this patch, the existence of an space for a
"SHOW CREATE TABLE table_name" statement was checked at runtime. This is
quite inconvenient for #4467, so this will now be checked when creating
the VDBE.

Needed for #4467

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

Before this patch, the existence of an index for a DROP INDEX statement
was checked at runtime. This is quite inconvenient for #4467, so this
will now be checked when creating the VDBE.

Needed for #4467

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

This patch refactors functions in pragma.c and fixes an issue with
incorrectly ordered arguments in sql_pragma_index_info().

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch removes the EP_InfixFunc, EP_DblQuoted and EP_Alias flags as
they are not used.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch removes the sql_id_eq_str_expr() and
vdbe_emit_stat_space_clear() functions as they are no longer used.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

Since tuple format cannot be created in IPROTO thread, we only save the
tuple format data and later create a tuple format map from it when
processing `call` and `eval` requests.

Closes #8633

@TarantoolBot document
Title: Tuple formats in IPROTO

New MsgPack extension was added, `MP_TUPLE`, which is used exclusively
in IPROTO. It has the following structure:
+----------+-----------------+----------+
|MP_EXT = 7|      MP_UINT    | MP_ARRAY |
+----------+-----------------+----------+
            ^                 ^
            format identifier tuple data

New IPROTO features were added:
* `IPROTO_FEATURE_DML_TUPLE_EXTENSION = 7` — tuples in `IPROTO_DATA` are
   encoded as `MP_TUPLE` and tuple format is sent in response to DML
   requests.
* `IPROTO_FEATURE_CALL_RET_TUPLE_EXTENSION = 8` —tuples in `IPROTO_DATA`
  are encoded as `MP_TUPLE` and tuple format is sent in response to `call`
  and `eval` requests.
* `IPROTO_FEATURE_CALL_ARG_TUPLE_EXTENSION = 9` — tuples in `IPROTO_TUPLE`
  of `call` and `eval` requests are encoded as `MP_TUPLE` with their
  formats encoded as described below.

The `IPROTO_FEATURE_DML_TUPLE_EXTENSION` feature can be enabled in
`net.box` by setting the `fetch_schema` option to `false` when creating a
new connection.

A new IPROTO key for bodies of responses with data and bodies of `call` and
`eval` requests: `IPROTO_TUPLE_FORMATS = 0x60` — a `MP_MAP` consisting of
`MP_UINT` keys (format identifiers) and `MP_STRING` values (tuple format
clauses).

A new backward compatibility option was added (and a new page,
`https://tarantool.io/compat/box_tuple_extension`, needs to be created for
it): `BOX_TUPLE_EXTENSION_BRIEF` — it controls the
`IPROTO_FEATURE_CALL_RET_TUPLE_EXTENSION` and
`IPROTO_FEATURE_CALL_ARG_TUPLE_EXTENSION` feature bits. It was added for
clients that assume to receive `MP_ARRAY`s in `call` and `eval` requests
arguments and response data.

Please refer to the design document for [details](https://www.notion.so/tarantool/Schemafull-IPROTO-cc315ad6bdd641dea66ad854992d8cbf?pvs=4#7d86000c69cb4f8087a289f2caad73a0).

Extend the MsgPack port to store a pointer to a MsgPack context (the
lifetime of a MsgPack port is static, so we simply allocate it on the
stack), avoiding copying. This context can later be used for dumping
MsgPack to Lua, and possibly acquired by a MsgPack object when the
'MsgPack object' mode of `port_dump_lua` is used.

Needed for #8147

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

Tuple formats are sent in a separate IPROTO_TUPLE_FORMATS response body
field, which is namely a mapping from format identifiers to serialized
tuple formats.

The algorithm for parsing IPROTO response body is the following:
1. Parse tuple formats and build a tuple format index.
2. Parse data passing the tuple format index in the decoding context.

Add new backward compatibility option `box_tuple_extension` which controls
the server's `IPROTO_FEATURE_CALL_RET_TUPLE_EXTENSION` bit: needed for
users that don't expect the new tuple extension to be returned in call and
eval responses instead of basic MsgPack types. This option will
also be used for `IPROTO_FEATURE_CALL_ARG_TUPLE_EXTENSION` bit with the
same purpose.

Closes #8147

NO_DOC=<added in a later commit together with documentation of tuple
        formats in IPROTO `call` and `eval` arguments>

In scope of tarantool/tarantool#8147, a new context-dependent extension for
box tuples, `MP_TUPLE`, is introduced. The buffer source uses a buffer with
raw MsgPack, which does not allow for passing the context required for
decoding `MP_TUPLE`, so, in order to decode it, we need to manually skip
the extension header and the tuple format identifier to get to the tuple
data and create a tuple. We can ignore the tuple format identifier (and the
tuple format that was originally sent for this tuple), since the format is
provided by the merger itself.

Needed for #8147

NO_CHANGELOG=<internal change>
NO_TEST=<tested by integration tests>
NO_DOC=<internal change>

Extend the MsgPack object creation interface to push a MsgPack context
required for decoding tuples coming from IPROTO, the context ownership is
acquired by the new object to avoid copying (thus, a virtual `move`
function is added to the MsgPack context).

When a MsgPack context is owned by a MsgPack object, the lifetime of the
former is controlled by the latter, hence a virtual `destroy` function is
added to the MsgPack context.

Needed for #8147

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

Add new MsgPack extension for tuples MP_TUPLE with the following structure:
+------+-----------------+----------+
|MP_EXT|      MP_UINT    | MP_ARRAY |
+------+-----------------+----------+
        ^                 ^
        format identifier tuple data

Needed for #8147

NO_CHANGELOG=<internal change>
NO_DOC=<internal change>

When data is coming from IPROTO and is passed to Lua, it is convenient to
pass raw MsgPack data (see `box.schema.func::takes_raw_args` option).
Currently, the port's MsgPack is retrieved directly via `port_get_msgpack`
and then a MsgPack object is constructed via `luamp_push`. In the future,
ports can have a MsgPack decoding context that will also be needed to be
passed to the MsgPack object constructor, so we encapsulate the MsgPack
object construction completely into a port method by introducing a new
operation mode to `port_dump_lua`.

This new operation mode is essentially a no-op for a MsgPack port (which is
the case for data coming from IPROTO), and is completely inefficient for
other types of ports (since an intermediate conversion to MsgPack occurs),
but we do not expect users to be calling Lua stored procedures with the
`takes_raw_args` locally. To handle the latter case we introduce a
`port_dump_lua_mp_object_mode_slow` helper function which facilitates
retrieving MsgPack data from ports via region allocation, creating a
Msgpack object and freeing the MsgPack data.

Needed for #8147

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

Currently, `port_dump_lua` has 2 modes of operation: 'flat' and 'tabular',
which are controlled via a boolean flag. We plan to extend it with another
mode of operation, 'Msgpack object', so we need to replace the flag with a
enumeration. Plus, this refactoring should improve readability.

Needed for #8147

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

In scope of #8633 call and eval encoding will require an additional
argument (whether to encode tuples as extensions and send formats), and
method encoders already have 3 arguments (MsgPack stream, IPROTO sync and
IPROTO stream identifier): to simplify further extension of method encoders
move arguments to a netbox_method_encode_ctx struct.

Needed for #8633

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

The MsgPack extension encoder has a strange interface: it returns the type
it has encoded the value to which at the same time indicates whether it has
succeeded in encoding the value — instead, let's return the type in an
output parameter and return the encoding status as a boolean value.

Needed for #8147

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

The MsgPack context structure is the essential data structure for
collecting and retrieving various meta information during MsgPack
encoding/decoding. This structure will be a base for a box-specific MsgPack
context (and, possibly, others), so we make it extendable by adding a
padding (to avoid dynamic allocations).

Refactor existing MsgPack encoding interfaces to use the MsgPack context
structure:
1. extend the port dumping interface, so that we can collect meta
information about dumped tuples' formats;
2. extend the port MsgPack retrieval interface, so that we can also
retrieve meta information about tuple formats for decoding tuples coming
from IPROTO (needed when decoding is postponed to a MsgPack object), the
context ownership is acquired by the caller to avoid copying;
3. extend the MsgPack encoding/decoding interfaces to accept a MsgPack
context to collect meta information during encoding or to use this meta
information for decoding — the context is passed down up to the extension
encoder/decoder, which is the point where future box tuple extension will
be processed.

Needed for #8147

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

The tuple format map is the essential data structure for collecting tuple
formats during box tuple encoding and for looking up tuple formats during
box tuple decoding.

Needed for #8147

NO_CHANGELOG=<internal data structure>
NO_DOC=<internal data structure>

Co-authored-by: Aleksandr Lyapunov <alyapunov@tarantool.org>

At the last itaration of review it was decided to throw an alerts,
when no UUID was passed to config and name is not set in _cluster.

This leads to alerts, thrown during replicaset bootstrap. However,
_cluster:on_replace trigger wasn't updated for that change, it
asssumed that when insert of a new replica is done, no alerts was
thrown.

Let's fix the behavior of on_replace trigger so that it deletes
alerts as soon as replica joined with name.

Follow-up #8978

NO_DOC=bugfix
NO_TEST=<already tested>
NO_CHANGELOG=bugfix