NO_CHANGELOG=fixed typos
NO_DOC=fixed typos
NO_TEST=fixed typos

The patch propagates debug mode to building of third party components:
c-ares, libcurl, libeio, nghttp2, zstd. Other components enables debug
mode automatically once it is enabled in Tarantool build.

Curl has two similar options that enables debug mode, however they are
different: `ENABLE_CURLDEBUG` enable memory debugging and `ENABLE_DEBUG`
restricts code which is only compiled for debug enabled builds [1].

1. https://everything.curl.dev/internals/memory-debugging

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

Fixed a bug when the assertion in box_promote_qsync would fail.
The assertion is that at the moment when box_promote_qsync is
executed, no other promote is executed. It turned out that this
assertion is basically incorrect. Now after this patch the newly
elected leader is trying to repeat box_promote_qsync in
box_raft_update_synchro_queue until it fails due to the fact
that some other promotion is currently being executed.

Closes #9263

NO_DOC=bugfix

This commit changes the order of configuration appliers and move
`console` before `box_cfg`. The `console` applier is adjusted to
correctly interpret the configured socket file path before the first
box.cfg().

The main reason to change the order is to allow a user to call
`box.ctl.make_bootstrap_leader()` for a replicaset that starts in the
`replication.boostrap_strategy: supervised` mode.

Part of #8862

NO_DOC=The documentation already assumes that a control command may be
       issued on the console. No changes are required.

It is important to listen on a Unix domain socket, because its path
length is limited to 107 on Linux and 103 on Mac OS (in our
implementation -- in theory could be 108 and 104).

Part of #8862

NO_DOC=no public API changes
NO_CHANGELOG=see NO_DOC
NO_TEST=negligible change

These functions are to be re-used in the console applier code in the
next commit. Exporting them allows to eliminate a duplication of this
code.

Part of #8862

NO_DOC=no public API changes
NO_CHANGELOG=see NO_DOC
NO_TEST=no new behavior, just refactoring

It is needed to verify the `supervised` bootstrap strategy. We should
start the instances, issue `box.ctl.make_bootstrap_leader` and only than
wait for `config:info().status == 'ready'`.

Let's support this flow in the replicaset management helper.

Part of #8862

NO_DOC=testing helper change
NO_CHANGELOG=see NO_DOC

Sometimes a testing code needs to interpret parts of the configuration
and it is convenient to look at the global scope only without diving
into group, replicaset, instance options.

Let's allow to set a global scope option in the configuration builder
helper.

Part of #8862

NO_DOC=testing helper change
NO_CHANGELOG=see NO_DOC

Before this patch a replica adds an alert regarding inability to write
new credentials from config on startup. In most cases these new
credentials are applied on a master and the warning becomes obsolete.
The problem is that it is not removed at this point. A manual
`config:reload()` is needed to flush it.

It makes the warning more confusing than helpful. Let's remove it for
now.

We can return the alert back in a future, but we should do it together
with a logic that drops the alert if the needed data is received from a
master.

Part of #8862

NO_DOC=bugfix

This patch sets requirements for vshard version that is supported by
config module.

Part of #8862

NO_TEST=internal

@TarantoolBot document
Title: config: supported vshard version

The vshard version supported by the config module cannot be less than
0.1.25. Note, that vshard will only be loaded if any of instances have
sharding storage role or sharding router role.

* FFI: Fix dangling reference to CType in carith_checkarg().
* FFI: Fix dangling reference to CType. Improve checks.
* FFI: Fix dangling reference to CType.
* FFI: Ensure returned string is alive in ffi.typeinfo().
* FFI: Fix missing cts->L initialization in argv2ctype().
* Abstract out on-demand loading of FFI library.
* test: fix flaky finalizer error handler tests
* test: adjust lua-Harness test error assertion
* Fix snapshot PC when linking to BC_JLOOP that was a BC_RET*.
* snap: check J->pc is within its proto bytecode
* Fix HREFK forwarding vs. table.clear().
* Fix FOLD rule for BUFHDR append.
* Prevent CSE of a REF_BASE operand across IR_RETF.
* test: rewrite sysprof test using managed execution
* test: disable buffering for the C test engine

Part of #9145

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump

To fix #9507 before release. We need more time to prepare a good patch
dealing with the issue.

This reverts commit 26acba83.

NO_TEST=fixing ASAN run of existing test
NO_CHANGELOG=issue is only in unreleased version
NO_DOC=bugfix

A recent TLS options support patchset (PR #9385) has changed a way to
work with URIs: they're now tables, not strings. So, a modification may
influence the original data.

Prevent it by copying a table before a modification.

Part of #8862

NO_DOC=bugfix
NO_CHANGELOG=the fixed code was not released yet
NO_TEST=no known failure scenarios

I accidentally discarded some changes made by @ImeevMA in PR #9385. The
previous version of the patchset goes to the main branch as result. I'm
very sorry.

This commit returns the code of the last version of the patchset.

The changes are described in [1]. Quoted here:

> 1. Reduce code duplication in the validation logic. It also
>    eliminates remaining (dead) code that interprets user@ and
>    user:pass@ syntax. And give better error messages in come cases
>    (comma separates URIs for example).
> 2. Forbid {} as an URI to simplify logic in instance_uri.
> 3. Refresh the comments.

[1]: https://github.com/tarantool/tarantool/pull/9385#discussion_r1430935585

Part of #8862

NO_DOC=fixup
NO_CHANGELOG=see NO_DOC

This patch adds missing field in instance_config_schema_test.lua.

Follow-up #9506

NO_DOC=fix for test
NO_CHANGELOG=fix for test

This patch updates example for vshard usage in config module.

NO_DOC=example update
NO_TEST=example update
NO_CHANGELOG=example update

Fixes #9506

@TarantoolBot document
Title: config.context: define cluster config parts in env/file

Example:

```yaml
config:
  context:
    replicator_password:
      from: file
      file: secrets/replicator_password.txt
      rstrip: true
    client_password:
      from: file
      file: secrets/client_password.txt
      rstrip: true

credentials:
  users:
    replicator:
      password: '{{ context.replicator_password }}'
      roles: [replication]
    client:
      password: '{{ context.client_password }}'
      roles: [super]
```

The new `config.context` section allows a user to define its own
variables, whose content resides in an environment variable or a file.

The primary usage is to extract passwords from the configuration.

All the variables are defined in `config.context` section as keys. Each
key is a record with the following fields.

* `from`: either `env` or `file`
* `file`: a file path
* `env`: an environment variable name
* `rstrip`: whether to strip whitespace characters from the end of the
   data (it strips newlines too)

A relative file path is interpreted as relative to `process.work_dir`.

`from` is mandatory, `file` is mandatory when `from` is `file`, `env` is
mandatory when `from` is `env`, `rstrip` is optional.

If there is no given file or no given environment variable, an error of
a configuration applying is reported.

The plan is to re-use it in a next commit.

Part of #9506

NO_DOC=no public API changes
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

NO_DOC=testing helper change
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

This patch enables vshard manual schema management mode.

Part of #8862

NO_DOC=internal
NO_CHANGELOG=internal

This patch introduces the sharding user role. This role must be set to
the vshard storage user, if user is in 'credentials.user'.

Part of #8862

@TarantoolBot document
Title: config: credential `sharding` role

The credential `sharding` role is a new credential role. This is the
default credential role, but it is different from other default
credential roles because it is created by the config module. Other
default credential roles are already described in the bootstrap.snap
file.

This role has different privileges depending on the replicaset sharding
role. For replicasets with the sharding `storage` role, the credential
`sharding` role will have rights to execute necessary `vshard.storage.*`
functions and the credential `replicaset` role. If the replicaset does
not have the sharding `storage` role, the credential `sharding` role
does not have any privileges.

A sharding storage user must have the credential `sharding` role among
their credential roles, if the user is in `credentials.users`. If the
user is not in `credentials.users` we do not check its privileges.

This patch adds missing tests to validate configs from doc/examples.

NO_DOC=tests for example configs
NO_CHANGELOG=tests for example configs

This patch moves example for config of config-storage to doc/examples
from enterprise doc/.

NO_DOC=added an example
NO_TEST=validation will be added later
NO_CHANGELOG=added an example

This patch fixes iproto.listen and iproto.advertise.peer in local.yaml.

Part of #8862

NO_DOC=changes in example
NO_TEST=will be tested in EE
NO_CHANGELOG=changes in example

When integrity protection is enabled, the Lua chunk given via -e option
is not run to avoid any effects from such a kind of platform behaviour
tweak. Fortunately, -e itself and its argument are stripped from the Lua
<arg> table, so the patch just omits the execution of the Lua chunk, and
there is no need for additional cleanup.

Part of tarantool/tarantool-ee#585

NO_DOC=will be added to Enterprise Edition
NO_TEST=will be added to Enterprise Edition
NO_CHANGELOG=will be added to Enterprise Edition

When integrity protection is enabled, the whole process environment is
purged to avoid any side effects from particular environment variables.
To totally collapse the effect of the environment, <clearenv> is invoked
at the beginning of Tarantool startup. Unfortunately, <proc_title_init>
helper relied on <environ> not being NULL, which led to the platform
crash during startup. The patch fixes this misbehaviour, either.

Part of tarantool/tarantool-ee#585

NO_DOC=will be added to Enterprise Edition
NO_TEST=will be added to Enterprise Edition
NO_CHANGELOG=will be added to Enterprise Edition

It turns out, GitHub actions don't allow `env` usage in their
definition. This patch fixes this issue in submodule bump action
by moving the environment definition into the executed shell
script.

NO_DOC=CI
NO_TEST=CI
NO_CHANGELOG=CI

Vshard now supports names instead of UUIDs in configuration. Let's
use them and finally drop generating UUIDs in config.

From now on we can recover instances without explicitly passing
UUIDs to configuration.

NO_DOC=<not released yet>
NO_CHANGELOG=<not released yet>

Co-authored-by: Mergen Imeev <imeevma@tarantool.org>

It fails in a quite stable manner after the previous commits. Let's
workaround it and fix it in the LuaJIT submodule later.

NO_DOC=no API changes
NO_CHANGELOG=no behavior changes
NO_TEST=nothing to test

This patch changes format of iproto.listen and introduces support for
TLS options in the iproto.listen config option.

Part of #8862

@TarantoolBot document
Title: new format of the `iproto.*` config options.

The config options `iproto.listen`, `iproto.advertise.peer` and
`iproto.advertise.sharding` now have a new format.

The `iproto.listen` config option now has the following format:
```
iproto:
  listen:
    - uri: <string>
      params:
        transport: <'plain' or 'ssl'>
        ssl_ca_file: <string>
        ssl_cert_file: <string>
        ssl_ciphers: <string>
        ssl_key_file: <string>
        ssl_password: <string>
        ssl_password_file: <string>
    - uri: <string>
      params:
        transport: <'plain' or 'ssl'>
        ssl_ca_file: <string>
        ssl_cert_file: <string>
        ssl_ciphers: <string>
        ssl_key_file: <string>
        ssl_password: <string>
        ssl_password_file: <string>
...
```
The `iproto.listen` config option is now an array, and its elements are
`records` that can only have a required `uri` field and an optional
`params` field.

The `uri` field is of type `string` and must be a single valid URI. The
URI cannot contain parameters, login and password.

The `params` field is a `record` with the fields `transport`,
`ssl_ca_file`, `ssl_cert_file`, `ssl_ciphers`, `ssl_key_file`,
`ssl_password`, `ssl_password_file`. The `transport` field can have one
of two values: `plain` or `ssl`, the default is `plain`. If `transport`
is set to `plain`, no additional fields are required. When `transport`
is set to `ssl`, the fields `ssl_key_file` and `ssl_cert_file` are
required, and the remaining fields are optional.

The `iproto.advertise.peer` and `iproto.advertise.sharding` now have the
following format:
```
iproto:
  advertise:
    <'peer' or 'sharding'>:
      uri: <string>
      login: <string>
      password: <string>
      params:
        transport: <'plain' or 'ssl'>
        ssl_ca_file: <string>
        ssl_cert_file: <string>
        ssl_ciphers: <string>
        ssl_key_file: <string>
        ssl_password: <string>
        ssl_password_file: <string>
```

The `iproto.advertise.peer` and `iproto.advertise.sharding` are now
`records`. All of their fields are optional, however, if the `params`
field can be set only if the `uri` field is set and the `password` field
can be set only if the `login` field is set.

The `uri` field is of type `string` and must be a single valid URI.
The URI cannot contain parameters, login and password. If the `uri` and
`params` fields are missing, the appropriate `iproto.listen` element is
selected. An element is eligible if, after parsing its `url` field using
`require('uri').parse()`, the `ipv4` result field is not equal to
`'0.0.0.0'`, the `ipv6` result field is not equal to `'::'`, and the
`service` result field is not equal to `'0'`.

The `login` and `password` fields are of type `string`.

For description of the `params` field see description of
`iproto.listen`.

This patch changes the structures of the iproto.advertise.peer and
iproto.advertise.sharding options and introduces TLS options for these
options.

There is no proper integration test for the new TLS options as our
iproto.listen does not currently support these options. The test will
be added along with the addition of TLS support in iproto.listen.

Part of #8862

NO_DOC=will be added later.

This patch fixes a crash that can occur when SQL parses a decimal
literal that represents a number greater than or equal to 10^38.

Closes #9469

NO_DOC=bugfix

This patch fixes a memory leak in sqlSelect that was caused by pWInfo
not being removed if an error occurred while encoding a GROUP BY
expression.

Closes #8535
Closes tarantool/security#125

NO_DOC=memleak
NO_TEST=memleak

This patch removes unused code that was previously used to check name
uniqueness for SQL constraints. Since SQL now uses the BOX constraint
mechanism, this code becomes unnecessary.

Follow-up #9112

NO_DOC=refactoring
NO_TEST=refacoring
NO_CHANGELOG=refactoring

Fixed incorrect argument order in sqlMatchSpanName(), which could lead
to incorrect query results.

Closes #9445

NO_DOC=bugfix

Deadlock is described in detail in the ticket. Let's don't wait while
connection that called iproto_drop_connections is deleted. It will be
deleted eventually when request executing iproto_drop_connections is
finished and all other requests in progress from this connection are
finished too (they are cancelled just as requests of other connections).

CE part of https://github.com/tarantool/tarantool-ee/issues/609

NO_DOC=bugfix
NO_CHANGELOG=feature is not released yet
NO_TEST=test is in EE

Each config reload on a node with old schema (less than 3.0.0) lead to
the error ER_SCHEMA_NEEDS_UPGRADE. This happened because the relevant
code didn't check for schema version before trying to apply the names.

Fix this.

Closes #9502

NO_DOC=bugfix
NO_CHANGELOG=fix in a not yet released behavior

The code in names_apply() and associated triggers considered the schema
to be up to date, if its version was >= 3.0.0. This was correct only for
the upcoming 3.0 release, but not for any releases coming after it.

Let's fix this by comparing schema version to mkversion.get_latest()
instead of a fixed 3.0.0 version.

In-scope-of #9502

NO_DOC=bugfix
NO_TEST=hard to test separately, covered by existing tests
NO_CHANGELOG=changes not yet released behavior

mkversion.get_latest() returns the latest schema version known to this
tarantool build. It is going to be used in config module to determine
when dd operations are allowed.

It will be used in places where `schema_needs_upgrade()` can't be used,
because it compares only the current schema version, not any version you
pass to it.

In-scope-of #9502

NO_DOC=internal
NO_TEST=covered by the next commit
NO_CHANGELOG=internal

Fixes #9452

@TarantoolBot document
Title: config: conditional sections for upgrading

See https://github.com/tarantool/tarantool/issues/9452 for the problem
statement. In short: some upgrade scenarios may need to configure
tarantool instances differently depending on a tarantool version.

A new top level configuration block is added for this purpose:
`conditional`. Let's look on an example:

```yaml
conditional:
- if: tarantool_version >= 3.99.0 && tarantool_version < 4.0.0
  # This section shouldn't be validated and shouldn't be applied.
  replication:
    new_option: foo
- if: tarantool_version < 3.99.0
  # This section is to be applied.
  process:
    title: '{{ instance_name }} -- in upgrade'
```

The block contains an array of conditional sections, each accompanied by
`if` predicate to determine, whether to apply it on particular tarantool
version. (`if` is required.)

If a section is not to be applied on the given version, it is not
validated at all and may contain unknown options.

If a section is to be applied, it must match the cluster configuration
schema like the main config.

If the same option is set by several sections with true predicate, the
last section wins.

The `if` expression supports one data type: `version`. A value may be
referenced in two ways:

1. Version literal: `1.2.3` (three components, not less, not more).
2. Variable: `tarantool_version` (only this variable is supported).

`tarantool_version` is assumed as three components version, say, 3.0.0.

The operations are the following.

1. Logical OR: `||`
2. Logical AND: `&&`
3. Compare: `>`, `<`, `>=`, `<=`, `==`, `!=`
4. Parentheses: `(`, `)`

All the comparisons assume the versions as three component ones.