Running of luacheck against test-run submodule is redundant.
Add dedicated bypass to .luacheckrc.

NO_DOC=ci
NO_CHANGELOG=ci
NO_TEST=ci

(cherry picked from commit 8d6a154f)

It looks like we just missed the fuzzing.yml workflow when worked on
adding this feature to our CI process in #6446.

Follows up tarantool/tarantool-qa#100

NO_DOC=ci
NO_CHANGELOG=ci
NO_TEST=ci

(cherry picked from commit dbaf03dc)

It looks like this trigger was added beforehand for some purposes
but never used. So there is no sense to keep it in our workflows.

NO_DOC=ci
NO_CHANGELOG=ci
NO_TEST=ci

(cherry picked from commit 88b46b4c)

We have recently moved all development from local branches to forks and
disabled running workflows in forks. So there is no sense to keep logic
for running full testing in forks if a branch has the 'full-ci' suffix.

NO_DOC=ci
NO_CHANGELOG=ci
NO_TEST=ci

(cherry picked from commit 1a0b5764)

We have recently moved all development from local branches to forks.
Most workflows cannot be run in forks because many of them need access
to private runners and/or secrets.

Workflows in forks can be disabled manually, but it's hard to remember
and it needs an extra action from a developer. Instead, we can detect
the repo in workflows and run them if the repo is tarantool/tarantool.

Closes #6913

NO_DOC=ci
NO_CHANGELOG=ci
NO_TEST=ci

(cherry picked from commit c27e6c74)

Run `docker run` with `--rm` to remove contaners after running
a container-based build.
These containers are never reused, so there's no reason to keep them.
Instead, a new container is created for each build.
Not removing them results in wasting disk space on CI runners.

NO_DOC=ci
NO_CHANGELOG=ci
NO_TEST=ci

(cherry picked from commit 065c2874)

See https://github.com/tarantool/checkpatch

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

(cherry picked from commit c86145b3)

This commit adds a new script, tools/check-commits. The script takes git
revisions in the same format as git-rev-list (actually, it feeds all its
arguments to git-rev-list) and runs some checks on each of the commits.

For example, to check the head commit, run:

  ./tools/check-commits -1 HEAD

To check the last five commits, run:

  ./tools/check-commits HEAD~5..HEAD

Currently, there are only two checks, but in future we may add more
checks, e.g. check diffs for trailing spaces:
 - The commit message contains a documentation request. Can be
   suppressed with NO_DOC=<reason> in the commit message.
 - A new changelog entry is added to changelog/unreleased by the commit.
   Can be suppressed with NO_CHANGELOG=<reason> in the commit message.

This commit also adds a new workflow triggered on pull request,
lint/commits. The workflow runs the tools/check-commits script on all
the commits added by the pull request. The workflow doesn't run on push,
because it's problematic to figure out what commits are new on a branch.
Besides, we don't want to run it on push to release branches, because
it's a pure dev workflow.

Example output:

Checking commit a33f3cc7 PASS
Checking commit 6f29f9d7 FAIL
SHA:     6f29f9d7
SUBJECT: iproto: introduce graceful shutdown protocol
  ERROR:
    Changelog not found in changelog/unreleased. If this commit
    doesn't require changelog, please add NO_CHANGELOG=<reason>
    to the commit message.
Checking commit fbc25aae FAIL
SHA:     fbc25aae
SUBJECT: Update small submodule
  ERROR:
    Missing documentation request ('@TarantoolBot document' not
    found in the commit message). If this commit doesn't need to
    be documented, please add NO_DOC=<reason> to the commit
    message.
  ERROR:
    Changelog not found in changelog/unreleased. If this commit
    doesn't require changelog, please add NO_CHANGELOG=<reason>
    to the commit message.

NO_DOC=ci
NO_CHANGELOG=ci

(cherry picked from commit 005fbb6b)

(cherry picked from commit 094c46b8)

Patch allows to run fuzzing in PR where label 'full-ci' is set.
Complememts a patch in commit "ci: enable fuzzing for *-full-ci
branches" (0115aab0).

Follows up #6630

(cherry picked from commit dc9c2117)

Part of #6681

(cherry picked from commit 78827e32)

Now it is not possible to run fuzzing on CI without merge to master
branch. Last time we missed [1] a broken compilation on merging new
fuzzers to master [2]. This patch enables fuzzing for branches with
postfix 'full-ci'.

1. https://github.com/tarantool/tarantool/pull/6757
2. https://github.com/tarantool/tarantool/pull/6627

(cherry picked from commit 0115aab0)

Problem:

For now, the integration testing runs only on a push of changes/tags
to the 'master' and release branches. This approach is not good enough
because we become aware of integration issues after the changes were
merged already to the target branch.

So this patch adds the facility to run the integration testing on a dev
branch to catch integration issues before the changes are merged to the
target branch. Now it can be done via naming the branch as `*-full-ci`
and pushing it to the main repository or setting the 'full-ci' label on
the pull request.

(cherry picked from commit 0c277b84)

The commit fixes the following test failure:

```
[011] engine/errinj_ddl.test.lua                      memtx           [ fail ]
[011]
[011] Test failed! Result content mismatch:
[011] --- engine/errinj_ddl.result      Tue Jan 18 15:28:21 2022
[011] +++ var/rejects/engine/errinj_ddl.reject  Tue Jan 18 15:28:26 2022
[011] @@ -343,7 +343,7 @@
[011]  s:create_index('sk', {parts = {2, 'unsigned'}}) -- must fail
[011]  ---
[011]  - error: Duplicate key exists in unique index "sk" in space "test" with old tuple
[011] -    - [101, 101, "xxxxxxxxxxxxxxxx"] and new tuple - [100, 101]
[011] +    - [100, 101] and new tuple - [101, 101, "xxxxxxxxxxxxxxxx"]
[011]  ...
[011]  ch:get()
[011]  ---
```

The test is inherently racy: a conflicting tuple may be inserted to the
new index either by the index build procedure or by the test fiber doing
DML in the background. The error messages will disagree regarding what
tuple should be considered old and which one new. Let's match the error
message explicitly.

The failure was introduced by d11fb306
("box: change ER_TUPLE_FOUND message") which enhanced error messages
with conflicting tuples.

(cherry picked from commit 197088c3)

During DDL operations triggers of old space and new created space
are swapped. This leads to crash in case if this swap occurs from
space on_replace triggers. This patch banned all DDL operations
from on_replace triggers.

Closes #6920

@TarantoolBot document
Title: Ban DDL operations from space on_replace triggers

Previously user can set function for space on_replace trigger,
which performs DDL operation. This may leads to tarantool crash,
that's why this patch bans DDL operations from on_replace triggers.
All this operations fails with error: "Space on_replace trigger
does not support DDL operations".

(cherry picked from commit e4e65e40)

When a request is redirected, old headers are of no use anymore and
should be dropped. We can detect a redirect by checking the value of
CURLINFO_REDIRECT_COUNT.

Note about the test: we change the redirect reply to 'redirecting...',
so that its length differs from 'hello world'.

Close #6101

NO_DOC=bug fix

(cherry picked from commit 1cde49d4)

NO_DOC=test
NO_CHANGELOG=test

(cherry picked from commit 57102048)

NO_DOC=test
NO_CHANGELOG=test

(cherry picked from commit fd142d71)

* ci: introduce GitHub Actions

NO_DOC=LuaJIT submodule bump
NO_CHANGELOG=no visible changes

Currently, we don't check tuple format in before_replace triggers,
that's why some bugs happen if we don't use the triggers correctly.

Let's check tuple format before execution of before_replace triggers
and after each before_replace trigger. The check will be disabled
during recovery for backward compatibility.

Closes #6780

NO_DOC=bug fix

(cherry picked from commit 884b3ff3)

The test checks key validation in before_replace trigger, but it
uses replace() to check it, and, as we plan to check tuple format in
before_replace trigger, we need to use something that works with
key, not tuple: delete(), for example.

Part of #6780

NO_DOC=refactoring
NO_CHANGELOG=refactoring

(cherry picked from commit 512ba6d5)

A secondary index creation proceeds as follows:
 1. Build the new index by inserting statements from the primary index,
    see vinyl_space_build_index().
 2. Dump the new index and wait for the dump to complete.
 3. Commit the index creation record to the WAL.

While the new index is being dumped at step 2, new statements may be
inserted into the space. We need to insert those statements during
recovery, see vy_build_recover(). We identify such statements by
comparing LSN to vy_lsm::dump_lsn, see vy_build_recover_stmt().

It might occur that the newly built index is empty while the primary
index memory level isn't - if all statements cancel each other. In this
case, the secondary index won't be dumped during creation and its
dump_lsn will be set to -1, see the vy_lsm_is_empty() check in
vinyl_space_build_index(). This would break the assumption made on
recovery: that all statements with LSN > vy_lsm::dump_lsn should be
inserted into the secondary index. If a statement like this isn't
compatible with the new index, we will get a crash trying to insert it.

Let's fix this issue by skipping vy_build_recover() in case the new
secondary index was never dumped.

Closes #6778

NO_DOC=bug fix

(cherry picked from commit dadb8d70)

Follow-up c28a3b2f
("test: remove checksums from suite.ini config files")

Return a more meaningful message about a malformed opts to
select, count and pairs methods of index object. Do not fail
with luajit error.

Also allow to pass specific iterator as a box.index.{ALL,...} directly.
For example, `s:pairs(nil, box.index.GT)`.

Fixes #6501

NO_DOC=bug fix

(cherry picked from commit 3a98e079)

Previous behaviour was quite illogical and unexpected. If user
once defined strict mode at start of tests it's expected that all
subtests also will have strict mode. However before this patch it
wasn't so. And wasn't clear at start why enabled strict mode
didn't work.
After this patch subtests strict mode will be the same as for
parent. This behaviour wasn't tested anyhow and wasn't documented.

Follow-up #4125

@TarantoolBot document
Title: clarify 'strict' behaviour in tap tests
Defined for root tap object strict mode will be the same for all
subtests.

Example:
```lua
t = require('tap').test('123')
t.strict = true

t:is_deeply({a = box.NULL}, {}) -- false

t:test('subtest', function(t)
    t:is_deeply({a = box.NULL}, {}) -- also false
end)
```

(cherry picked from commit 676582c4)

Before this patch comparison of two `false` values produced
incorrect result. That because nil and false are consieded in the
same way by if operator. This patch fixes an issue and introduces
corresponding tests.

Closes #6386

NO_DOC=bugfix

(cherry picked from commit 840a45c4)

The luatest_helpers.lua module confuses developers because luatest
itself has the helpers.lua module as well. It is unclear which one
should be used and when because it is hard to remember what stuff
provides each of them.

Actually, luatest_helpers.lua has functions that can be safely moved to
more proper places (luatest_helpers/server.lua & instances/default.lua).

The `get_vclock` function logically belongs to server stuff, so it was
moved to server.lua and slightly changed (`eval` call was replaced by
`exec`).

The `wait_vclock` function logically belongs to server stuff as well, so
it was moved to server.lua without changes.

The `instance_uri` function logically belongs to server stuff as well,
so it was moved to server.lua and slightly changed (it was renamed into
`build_instance_uri` and redundant `instance_id` param was dropped).

The `default_cfg`, `env_cfg`, `box_cfg` functions logically belongs to
instance stuff, so they were moved to default.lua without changes.

Thus, the luatest_helpers.lua module was dropped and tests using this
module were updated.

Closes tarantool/luatest#192

NO_DOC=testing stuff
NO_CHANGELOG=testing stuff

(cherry picked from commit c3253d89)

The luatest_helpers/asserts.lua module confuses developers because
luatest itself has the asserts.lua module as well. It is unclear which
one should be used and when because it is hard to remember what stuff
provides each of them.

Actually, luatest_helpers/asserts.lua has functions that are not really
about asserting and can be safely moved to more proper places like the
luatest_helpers/server.lua and luatest_helpers/cluster.lua modules.

The `assert_server_follow_upstream` function logically belongs to server
stuff, so it was moved to server.lua and slightly changed (renamed into
`assert_follows_upstream` and `eval` calls were replaced by `exec`).

The `wait_fullmesh` function logically belongs to cluster stuff, so it
was moved to cluster.lua and slightly changed (now it accepts one param
that can include wait timeout and delay, otherwise, defaults applied).

Thus, the luatest_helpers/asserts.lua module was dropped and tests using
this module were updated.

Part of tarantool/luatest#192

NO_DOC=testing stuff
NO_CHANGELOG=testing stuff

(cherry picked from commit dbcb2d53)

It takes box.cfg config as an argument. And changes the argument
by adding a new key 'command'. If the caller wants to pass the
same box.cfg or slightly modified to several build_server() calls,
it won't work - all options will be the same on all instances.

For example:

    local cfg = {...}
    cfg.replication = {url1}
    cluster:build_server(cfg)
    cfg.replication = {url2}
    cluster:build_server(cfg)

It will not work. Both servers will get the same 'command' and the
same 'replication'.

(cherry picked from commit 33ea6824)

We have recently dropped 'checksum' machinery in test-run
(tarantool/test-run#321) and now there is no need to keep
checksums in suite.ini config files. So removing them.

Closes tarantool/tarantool-qa#152

(cherry picked from commit fc177b33)

* test: adapt tests checking loading bytecode files
* test: adapt disabled tests from PUC-Rio
* test: adapt tests checking traceback in tail call
* test: adapt test checking global environment

Closes #5687
Closes #5691
Closes #5703
Closes #5713
Part of #5870

NO_DOC=LuaJIT submodule bump
NO_CHANGELOG=no visible changes

Bump test-run to new version with the following improvements:

  - drop 'checksum' machinery (tarantool/test-run#316)
  - rerun fragile tests only with status == 'fail'

NO_DOC=testing stuff
NO_CHANGELOG=testing stuff

(cherry picked from commit a70797f1)

The function of the question (`tarantoolsqlIdxKeyCompare()`) compares a
tuple with a key. It extracts necessary fields from the tuple and runs
the compare function, which is basically `memcmp()` of two buffers (for
`varbinary` values -- numeric comparisons are different).

In the Debug build the function also re-verifies the result using a
separate comparison code. And here we compare two `memcmp()` return
values.

We shouldn't do it directly, because `memcmp()` only guarantees sign of
the result. Please, consider the linked issue for details.

NO_DOC=only debug build is affected
NO_CHANGELOG=only debug build is affected
NO_TEST=hard to create a stable reproducer

Fixes #6849

(cherry picked from commit 330100bf)

- Improve reporting from failed luatest tests (tarantool/test-run#319)
- Update luatest to 0.5.7 (tarantool/test-run#322)

(cherry picked from commit e4f9d040)

* gdb: add mmudata value to lj-gc output
* gdb: unwind Lua stack top part

It was added to the master by a patch that introduced a new feature so
we it wasn't backported. As a result, the tests were never run.

The is_multikey option must be wrapped in opts, because commit
66f5368b ("schema: allow to pass
is_multikey func opt without sub-table") wasn't backported.

From time to time we can see failures of one of `box-luatest` tests.
It's `gh_6794_recover_nonmatching_xlogs.test_ignore_with_force_recovery`
test:

    [021] box-luatest/gh_6794_recover_nonmatching_xlogs_>
    [021] not ok 2 box-luatest.gh_6794_recover_nonmatching_xlogs.test_ignore_with_force_recovery #
    [021] Rejected result file: /tmp/tnt/rejects/box-luatest/gh_6794_recover_nonmatching_xlogs.reject
    [021] [ fail ]

More detailed failure log:

    not ok 2	box-luatest.gh_6794_recover_nonmatching_xlogs.test_ignore_with_force_recovery
    #   .../tarantool/test/luatest_helpers/server.lua:99: Waiting for "readiness" on server master-UCg6PXluSqYt (PID 85920) timed out
    #   stack traceback:
    #   	.../tarantool/test/luatest_helpers/server.lua:99: in function 'wait_for_readiness'
    #   	.../tarantool/test/luatest_helpers/server.lua:146: in function 'start'
    #   	...t/box-luatest/gh_6794_recover_nonmatching_xlogs_test.lua:32: in function 'box-luatest.gh_6794_recover_nonmatching_xlogs.test_ignore_with_force_recovery'
    #   	...
    #   	[C]: in function 'xpcall'

If we take a look at the log of a tarantool server that is used for
testing, we will see the failure reason:

    2022-02-04 21:06:12.063 [85920] main/103/default.lua evio.c:240 E> SocketError: unlink, called on fd 27, aka unix/:(socket), peer of unix/:(socket): Address already in use
    2022-02-04 21:06:12.063 [85920] main/103/default.lua F> can't initialize storage: unlink, called on fd 27, aka unix/:(socket), peer of unix/:(socket): Address already in use

Both tests from the gh_6794_recover_nonmatching_xlogs_test.lua file used
the same alias (master) for the tarantool server, hence in both tests
the tarantool server used a socket with the same name (master.iproto).
So we had a race here: if the socket from the previous test was released
in time, our test succeeded, otherwise, failed.

To fix the issue it was decided to create tarantool servers with
different aliases. This gives us sockets with different names, hence no
socket intersection.

Closes tarantool/tarantool-qa#151

NO_CHANGELOG=test stuff
NO_DOC=testing stuff

(cherry picked from commit 3f86cd04)

All tests from the update_optimize.test.lua file were fully migrated
to the luatest framework. The old test files were deleted.

Closes #6556

NO_CHANGELOG=testing stuff
NO_DOC=testing stuff

(cherry picked from commit 1b0bd504)

On completion of compaction tasks we remove compacted run files created
after the last checkpoint immediately to save disk space. In order to
perform this optimization we compare the unused runs' dump LSN with the
last checkpoint's one.

But during replica's initial JOIN stage we set the LSN of all rows
received from remote master to 0 (see
box/box.cc/boostrap_journal_write). Considering that the LSN of an
initial checkpoint is also 0, our optimization stops working, and we
receive a huge disk space usage spike (as the unused run files will
only get removed when garbage collection occurs).

We should check the vinyl space engine's status and perform
our optimization unconditionally if we are in replica's initial JOIN
stage.

Closes #6568

(cherry picked from commit 599f0c13)