__tostring always returns the type name, which is 'net.box.request'.

__serialize returns user-defined fields attached to the future or an
empty table if there's none.

Closes #6314

The new version (2.10.0) is considered to be lower than 2.2.1, because
the test uses string comparison, which results in a test failure.

Remove the useless check.

Four changelog entries were fixed to resolve syntax errors.

The new release policy suggests to use X.Y.Z-alphaN, X.Y.Z-betaN,
X.Y.Z-rcN tags for pre-releases. See the policy document here:
https://github.com/tarantool/tarantool/discussions/6182

This commit enforces the new versioning for tarantool builds that're
made from CI.

Tarballs
--------

When we'll add the 2.10.0-beta1 tag, the tarball will be named so:

> tarantool-2.10.0-beta1.tar.gz

When we'll add one commit upward the tag, the tarball will be named so:

> tarantool-2.10.0-beta1.1.dev.tar.gz

(In fact, we don't deploy tarballs per push anymore, so it is just for
the same of completeness.)

For 2.10.0 release it'll be named as:

> tarantool-2.10.0.tar.gz

How to try: `make -f .gitlab.mk source`.

Packages
--------

When we'll add the 2.10.0-beta1 tag, the packages for Ubuntu Focal will
be named so:

> tarantool_2.10.0~beta1-1_amd64.deb
> tarantool-common_2.10.0~beta1-1_all.deb
> tarantool-dev_2.10.0~beta1-1_amd64.deb

The sources packaged together with the package will be named so:

> tarantool_2.10.0~beta1-1.debian.tar.xz
> tarantool_2.10.0~beta1-1.dsc
> tarantool_2.10.0~beta1.orig.tar.xz
> tarantool-2.10.0~beta1.tar.xz

When we'll add one commit upward the tag, those files will look so:

> tarantool_2.10.0~beta1.1.dev-1_amd64.deb
> tarantool-common_2.10.0~beta1.1.dev-1_all.deb
> tarantool-dev_2.10.0~beta1.1.dev-1_amd64.deb

> tarantool_2.10.0~beta1.1.dev-1.debian.tar.xz
> tarantool_2.10.0~beta1.1.dev-1.dsc
> tarantool_2.10.0~beta1.1.dev.orig.tar.xz
> tarantool-2.10.0~beta1.1.dev.tar.xz

(In fact, we don't deploy packages per push anymore, so it is just for
the same of completeness.)

For 2.10.0 release it'll be named so:

> tarantool_2.10.0.gcb3bdbf2a-1_amd64.deb
> tarantool-common_2.10.0.gcb3bdbf2a-1_all.deb
> tarantool-dev_2.10.0.gcb3bdbf2a-1_amd64.deb

> tarantool_2.10.0.gcb3bdbf2a-1.debian.tar.xz
> tarantool_2.10.0.gcb3bdbf2a-1.dsc
> tarantool_2.10.0.gcb3bdbf2a.orig.tar.xz
> tarantool-2.10.0.tar.xz

How to try: `OS=ubuntu DIST=focal make -f .gitlab.mk package`.

Fixes #6184

See the previous commit 'test: descrease instance file name length' for
the problem description.

Since we're going to use the tags like 2.10.0-beta1 for upcoming
pre-releases, we have even less symbols for a filename of a unix socket.
So I chose the shorter names on the test-run side: foo.socket-iproto ->
foo.i, foo.socket-admin -> foo.c (console).

See https://github.com/tarantool/test-run/pull/312

This update is mostly necessary for the current master branch, but it'll
be applied for 1.10 as well: we keep test-run consistent across alive
branches.

Part of #6184

First, several facts:

* The maximal unix socket file length is 108 symbols on Linux (in fact,
  107 for tarantool console socket, see #4634).
* We run testing during building of RPM packages.
* When tests are run, they use the build directory for temporary testing
  files and tarantool console unix socket files.
* Test-run uses an instance script name to form a unix socket name for
  tarantool console.
* We plan to change package version format and add .dev suffix for
  transient (non tagged) commits.
* The package version participates in the build directory name, when
  we're building an RPM package.

If we'll enable the new version format just now, we'll unable to listen
on the unix socket like the following (the length is 111):

```
/build/usr/src/debug/tarantool-2.9.0.353.dev/test/var/023_box/gh-3633-simple-tuple-size-increasing.socket-admin
```

So I changed the instance file name to make it shorter.

Of course, there are ways to solve the problem at all, this commit is
just workaround.

Part of #6184
Follows up #3633

Was added 'export DEBIAN_FRONTEND=noninteractive', because there are
packages, which are noninteractive by default. So, CI raises
'Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?'.

Were added workflows with *.rpm or *.deb packaging for arm architecture.
Those workflows only verify package builds and don't deploy them to our
repositories for now.

Part of #6222

Tests were turned off from arm workflows according to instability.

Needed for #6222

It requires update_repo.sh changes, which are not trivial in
verification. We want to be sure that all apt/yum metainformation is
generated correctly, so we'll postpone the automatic deployment task.

Part of #6222

Follows up #6185

This patch enables static and dynamic type check for functions SUBSTR(),
GROUP_CONCAT(), REPLACE(), TRIM(). All these functions afther this patch
will be able to return VARINARY value when VARBINARY arguments are given
instead of STRING arguments.

Closes #6105

This patch enables static and dynamic type check for aggregate functions
SUM(), AVG() and TOTAL().

Part of #6105

Prior to this, the patch functions MIN(), MAX(), LEAST() and GREATEST()
showed SCALAR as result types in metadata. However, in reality, the type
of the result could be any scalar type. After this patch, the type of
the result will always be the same as the type in the metadata. Also,
for MIN() and MAX() functions, the type of the result will be the same
as the type of the argument. For the LEAST() and GREATEST() functions,
the result type will be the same as the type of the arguments if all
arguments are of the same type, or it will be NUMBER if all arguments
are of numeric types, or it will be SCALAR.

Part of #6105

This patch enables static and dynamic type checks for functions that do
not need any rework.

Part of #6105

This patch introduces a runtime type checking mechanism for SQL built-in
functions. However, it is currently disabled as the functions themselves
need to be prepared for such changes.

Part of #6105

This patch introduces a static type checking mechanism for SQL built-in
functions. However, it is currently disabled as the functions themselves
need to be prepared for such changes.

Part of #6105

Prior to this patch, the number of arguments for functions with a
variable number of arguments was checked at runtime. After this patch,
it will be checked during parsing. For functions with a constant number
of arguments, it is always checked during parsing.

Part of #6105

Currently, the SQL built-in hash table contains one already defined
implementation for each SQL built-in function. This is rather
inconvenient because some built-in SQL functions can accept arguments of
more than one type, and the type of the result can depend on the types
of the arguments. In addition, the number of arguments can be variable
for some built-in SQL functions. For these reasons, we are forced to
check the number of arguments and their type at runtime. To make it
possible to check types of arguments and their number during parsing,
the hash table has been modified so that functions can now have more
than one implementation.

Part of #6105

This patch changes the signature of SQL built-in function TRIM(). This
gives us an easier way to check the types of the arguments to this
function. Additionally, these changes fix a bug where using TRIM with
the BOTH, LEADING, or TRAILING keywords would result in a loss of a
collation.

Needed for #6105
Closes #6299

Follow-up #6185

After this patch SQL built-in function QUOTE() will return the argument
in case DOUBLE value is given. If the argument is not number, string
representation of the argument will be returned.

Closes #6239

@TarantoolBot document
Title: QUOTE() and DOUBLE argument

After this patch function QUOTE() will return argument in case it
receives DOUBLE value as an argument. The same for all other numeric
types. In case it was given value of non-numeric type, it will return
string representation of the argument.

New release policy defines pre-release tags: *-alpha*, *-beta*, *-rc*.
Packages with these tags must be published to pre-release folder in
the S3 repo. Was added PRERELEASE_REPO_S3_DIR path to all workflows with
packaging *.rpm and *.deb and fixed conditions for updating the S3 repo.

Needs for: #6185

New release policy provides new rules for publishing packages.
Now, only major version is defining bucket repo, for more convenience
use next naming series-<MAJOR_VERSION>.

Needs for: #6185

According to the new release policy live packages are not allowed.
Only releases and pre-releases would be published to the S3.

Needs for: #6185

This patch enables all tests in tarantool/luajit to be run in CI, since
all issues found with them are finally resolved in scope of the commit
847b096e ('luajit: bump new version').

Follows up #6098
Follows up tarantool/tarantool-qa#120

Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Reviewed-by: Vitaliia Ioffe <v.ioffe@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

* ARM64: Fix exit stub patching.
* arm64: fix cur_L restoration on error throw

Closes #6098
Closes #6189
Part of #5629
Relates to #6323
Follows up #1516

This patch adds changelog entry for commit
027775ff ('lua: refactor
port_lua_do_dump and encode_lua_call').

Follows up #6248
Follows up #4617

Signed-off-by: Igor Munkin <imun@tarantool.org>

This patch adds changelog entry for commit
ba5398c7 ('luajit: bump new version').

Follows up #6224
Follows up #6227

Signed-off-by: Igor Munkin <imun@tarantool.org>

This patch introduces arithmetic for DECIMAL in SQL. After this patch,
DECIMAL values can participate in arithmetic along with INTEGER,
UNSIGNED, DOUBLE, and other DECIMAL values.

Part of #4415

This patch introduces implicit and explicit cast of the DECIMAL field in
SQL. Implicit cast to and from DECIMAL is precise. Explicit conversion
to decimal and back could lead to loss of precision.

Part of #4415

This patch introduces a decimal field type. However, implicit and
explicit casts and arithmetic operations for this type will be presented
in next few patches. Literals also will be introduced later.

Part of #4415

This patch introduces function decimal_is_neg() which checks that
decimal is less than zero.

Needed for #4415

RW transactions used to commit without problems after rollback
of transactions holding stories responsible to track their reads.
That behaviour led to unserializable results.
This patch fixes this problem.

Closes #6325

There are two cases in lua trigger implementation, which leads
to access to freed memory: if trigger removes itself and if
trigger yields and someone destroy it. These problems was fixed
by remembering the necessary fields from the trigger structure
in local variables before calling trigger function.

Closes #6266

After this patch, SCALAR values will be able to be compared with values
of any other scalar type. The comparison will be done according to the
SCALAR rules, which means boolean values < numeric values < string
values < binary values < uuid values.

Closes #6221

@TarantoolBot document
Title: SCALAR and NUMBER values in SQL

SCALAR values can now be compared with values of any other scalar type,
but cannot be implicitly cast to any other scalar type. This means that
SCALAR values cannot participate in arithmetic, bitwise operations,
concatenation, or functions that, by definition, do not accept SCALAR
values.

NUMBER values now also cannot be implicitly cast to any other numeric
type, which means that NUMBER values cannot participate in arithmetic
and bitwise operations, or in functions that, by definition, do not
accept NUMBER values.

Part of #6221