Prior to this patch, it was possible to call box.execute() before box
was initialized, i.e. before calling box.cfg(). This, however, caused
box.cfg() to be called automatically, which could be problematic as some
parameters could not be changed after box.cfg() was called. After this
patch, box.execute() will only be available when the box has been
initialized.

Closes #4726

@TarantoolBot document
Title: box.execute() now available only after initialization of box

Previously, it was possible to call box.execute() before the box was
configured, in which case the box was configured automatically, which
could lead to problems with box parameters. Now box.execute() can only
be called after the box has been properly configured.

It is also forbidden to set language to SQL in a console with an
unconfigured box.

Fix a simple typo that caused the problem.

Closes #7645

NO_DOC=bugfix

This patch introduces new rules to determine type of NULLIF() built-in
function.

Closes #6990

@TarantoolBot document
Title: New rules to determine type of result of NULLIF

The type of the result of NULLIF() function now matches the type of the
first argument.

This patch introduces new rules to determine type of CASE operation.

Part of #6990

@TarantoolBot document
Title: New rules to determine type of result of CASE

New rules are applied to determine the type of the CASE operation. If
all values are NULL with no type, or if a bind variable exists among
the possible results, then the type of CASE is ANY. Otherwise, all NULL
values with no type are ignored, and the type of CASE is determined
using the following rules:
1) if all values of the same type, then type of CASE is this type;
2) otherwise, if any of the possible results is of one of the
incomparable types, then the type of CASE is ANY;
3) otherwise, if any of the possible results is of one of the
non-numeric types, then the type of CASE is SCALAR;
4) otherwise, if any of the possible results is of type NUMBER, then the
type of CASE is NUMBER;
5) otherwise, if any of the possible results is of type DECIMAL, then
the type of CASE is DECIMAL;
6) otherwise, if any of the possible results is of type DOUBLE, then the
type of CASE is DOUBLE;
7) otherwise the type of CASE is INTEGER.

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

- vy_cache.test
- vy_mem.test
- vy_point_lookup.test
- vy_write_iterator.test

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Updated swim.test, swim_errinj.test, swim_proto.test
to activate TAP-compatible mode.

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Updated mhash.test and mhash_bytemap.test to
activate TAP-compatible mode.

Part of #7618
NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7618

NO_DOC=internal
NO_CHANGELOG=internal

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

The commit c1c77782 ("replication: fix bootstrap failing with
ER_READONLY") made applier retry connection infinitely upon receiving a
ER_READONLY error on join. At the time of writing that commit, this was
the only way to make join retriable. Because there were no retries in
scope of bootstrap_from_master. The join either succeeded or failed.

Later on, bootstrap_from_master was made retriable in commit
f2ad1dee ("replication: retry join automatically"). Now when
bootstrap_from_master fails, replica reconnects to all the remote nodes,
thus updating their ballots, chooses a new (probably different from the
previous approach) bootstrap leader, and retries booting from it.

The second approach is more preferable, and here's why. Imagine
bootstrapping a cluster of 3 nodes, A, B and C in a full-mesh topology.
B and C connect to all the remote peers almost instantly, and both
independently decide that B will be the bootstrap leader (it means it
has the smallest uuid among A, B, C).

At the same time, A can't connect to C. B bootstraps the cluster, and
joins C. After C is joined, A finally connects to C. Now A can choose a
bootstrap leader. It has an old B's ballot (smallest uuid, but not yet
booted) and C's ballot (already booted). This is because C's ballot is
received after cluster bootstrap, and B's ballot was received earlier
than that. So A believes C is a better bootstrap leader, and tries to
boot from it.

A will fail joining to C, because at the same time C tries to sync with
everyone, including A, and thus stays read-only. Since A retries joining
to the same instance over and over again, this situation makes the A and
C stuck forever.

Let's retry ER_READONLY on another level: instead of trying to join to
the same bootstrap leader over and over, try to choose a new bootstrap
leader and boot from it.

In the situation described above, this means that A would try to join to
C once, fail due to ER_READONLY, re-fetch new ballots from everyone and
choose B as a join master (now it has smallest uuid and is booted).

The issue was discovered due to linearizable_test.lua hanging
occasionally with the following output:
NO_WRAP
 No output during 40 seconds. Will abort after 320 seconds without output. List of workers not reporting the status:
- 059_replication-luatest [replication-luatest/linearizable_test.lua, None] at /tmp/t/059_replication-luatest/linearizable.result:0
[059] replication-luatest/linearizable_test.lua                       [ fail ]
[059] Test failed! Output from reject file /tmp/t/rejects/replication-luatest/linearizable.reject:
[059] TAP version 13
[059] 1..6
[059] # Started on Thu Sep 29 10:30:45 2022
[059] # Starting group: linearizable-read
[059] not ok 1	linearizable-read.test_wait_others
[059] #   ....11.0~entrypoint.531.dev/test/luatest_helpers/server.lua:104: Waiting for "readiness" on server server_1-q7berSRY4Q_E (PID 53608) timed out
[059] #   stack traceback:
[059] #   	....11.0~entrypoint.531.dev/test/luatest_helpers/server.lua:104: in function 'wait_for_readiness'
[059] #   	...11.0~entrypoint.531.dev/test/luatest_helpers/cluster.lua:92: in function 'start'
[059] #   	...t.531.dev/test/replication-luatest/linearizable_test.lua:50: in function <...t.531.dev/test/replication-luatest/linearizable_test.lua:20>
[059] #   	...
[059] #   	[C]: in function 'xpcall'
NO_WRAP

Part-of #7737

NO_DOC=bugfix

Usually, GitHub actions are named like `foo-bar` rather than `foo_bar`.
A few widely known examples: upload-artifact [1], download-artifact [2],
setup-python [3], setup-node [4]. So let's stick to this approach also.

[1] https://github.com/actions/upload-artifact
[2] https://github.com/actions/download-artifact
[3] https://github.com/actions/setup-python
[4] https://github.com/actions/setup-node

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

This patch fixed the assertion when using INDEXED BY with an index that
is at least the third in space.

Closes #5976

NO_DOC=bugfix

If the length of the tuple is greater than the number of fields in the
format, it is possible that the cursor in the VDBE will be overridden
with zeros.

Closes #5310

NO_DOC=bugfix

* FFI: Always fall back to metamethods for cdata length/concat.
* FFI: Add tonumber() specialization for failed conversions.
* build: introduce LUAJIT_ENABLE_CHECKHOOK option
* Fix overflow check in unpack().
* gdb: refactor iteration over frames while dumping stack
* gdb: adjust to support Python 2 (CentOS 7)

Closes #7458
Closes #7655
Needed for #7762
Part of #7230

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump

dt.new() will raise a clear error on wrong timestamp type.

Closes #7273

NO_DOC=bugfix
NO_CHANGELOG=bugfix

For reasons described in #7231 HASH index 'GT' iterator type is deprecated:
print a warning exactly once about the deprecation.

Closes #7231

@TarantoolBot document
Title: memtx HASH index 'GT' iterator deprecation

memtx HASH index 'GT' iterator is deprecated since Tarantool 2.11
(tarantool/tarantool#7231) and will removed in a future release of
Tarantool: the user will get a warning when using it.

It's incorrect to create a tuple format when a read view is created,
because the tuple format registry isn't MT-safe so accessing a tuple
format created in the main thread from another thread by id (for
tuple_format(tuple)) may not work as expected. To address this issue,
we'll introduce a thread-local tuple format-registry. As a preparation
for this, let's create the tuple format when a read view is activated
by the thread that's going to use it (see the EE repository) while on
read view creation we now create only a field definition array necessary
to construct the format.

Needed for https://github.com/tarantool/tarantool-ee/issues/247

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring