It's better than hand-written busy-wait.

The commit fixes the following test failure:

```
[013] vinyl/gc.test.lua                                               [ fail ]
[013]
[013] Test failed! Result content mismatch:
[013] --- vinyl/gc.result	Fri Dec 24 12:27:33 2021
[013] +++ /build/usr/src/debug/tarantool-2.10.0~beta2.18.dev/test/var/rejects/vinyl/gc.reject	Thu Dec 30 10:29:29 2021
[013] @@ -102,7 +102,7 @@
[013]  ...
[013]  check_files_number(2)
[013]  ---
[013] -- true
[013] +- null
[013]  ...
[013]  -- All records should have been purged from the log by now
[013]  -- so we should only keep the previous log file.
```

The reason of the failure is that vylog files are deleted asynchronously
(`box.snapshot()` doesn't wait for `unlink` to complete) since commit
8e429f4b ("wal: remove old xlog files
asynchronously"). So to fix the test, we just need to make the test wait
for garbage collection to complete.

Follow-up #5383

When `slab_get` is called from `region_alloc` or `ibuf_alloc` first
of all we try to calculate order of appropriate slab. But there is
no check that requested size with slab meta is <= UINT32_MAX, that
leads to assertion failer in `slab_order` function. There is no
need for this assertion we should return `cache->order_max + 1`
for this case.

Closes #6726

This required some test refactoring for tests which rely on quorum being
"1" by default.

Closes #5966
Prerequisite #6471

This patch brings consistency to OSX workflow names with other workflow
names.

The following changes were made:

  * Arch suffix changed (arm64 -> aarch64)
  * Minor OS version removed (11_2 -> 11)
  * Specific options moved to the end of the workflow name
    (osx_debug_xyz.yml -> osx_xyz_debug.yml)

Closes tarantool/tarantool-qa#149

Now `## bugfix/luajit` and `## bugfix/LuaJIT` entries will form one
section.

Now one can write either `## bugfix/luajit` or `## bugfix/LuaJIT`. The
latter will NOT be transformed into `### Luajit` anymore. Both variants
now give `### LuaJIT` section inside `## Bugs fixed` section.

See `REDEFINITIONS` variable inside the script to understand how well
known headers (such as `## <...>/LuaJIT`) are prettified.

There is a problem with section grouping, when headers are written in
lower/title/mixed case. It'll be resolved in a next commit.

We run the script in CI as linter (see PR #6701), so it should handle
lack of any changelog entries gracefully.

Previously the script mistakely requires at least one feature and at
least one bugfix. However it is quite natural to have only bugfixes in a
bugfix release. Moreover, we added the script into CI as linter (see
PR #6701), so it should work even when we just start filling release
notes.

Git does not store empty directories, but it is convenient for us to
have this directory always.

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

Fuzzing workflow has been disabled due to warnings (treated by errors)
on compilation with Clang 14 that is used as a default compiler in
OSS-Fuzz infrastructure and missed libunwind in a test env where fuzzers
run. Compilation warnings were fixed in a previous commit and problem
with missed libunwind library has been resolved by patch to OSS-Fuzz
[1].

Follows up #6681

1. https://github.com/google/oss-fuzz/pull/7110

Part of #6681

Add ubuntu-impish workflow, which runs on push and pull-requests.

Closes #6566

The test for the 'unicode_de__phonebook_s3' collation from
sql-tap/collation_unicode.test.lua fail if the ICU version >= 70.1.
So let's temporarily mark it as unstable until the issue is resolved.

See for more details tarantool/tarantool#6695.

Fuzzing is disabled until #6681 is resolved.

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

Since the auxiliary libraries are built as dynamically loaded modules on
macOS instead of shared libraries as it is done on Linux and BSD,
another environment variable should be used to guide `ffi.load()` while
searching the extension. Hence the paths are set in test need to be set
to `DYLD_LIBRARY_PATH` variable instead of `LD_LIBRARY_PATH` on macOS.

New workflow was copy-and-pasted from macOS 11 workflow
and patched obviously.

NB: it seems like app-tap/popen test is constantly failing
on macOS ver. 12. Disable until it is fixed.

Part of #6739

I have no idea what this trailing zero stands for.
Drop it.

We support current and previous version of macOS.
So let's remove 10.15 from CI.

We're about to stop CI for macOS version 10.15. But
seems (for now) we still interested in LTO on mscOS.
So, move LTO testing to macOS version 11.

Part of #6739

This patch extends the 'integration.yml' workflow and adds a new
workflow call for running tests to verify integration between tarantool
and the memcached module.

Part of #5265
Part of #6056
Closes #6563

Now scan.coverity.com reports "Overrunning buffer pointed to by
&map of 4 bytes by passing it to a function which accesses it at
byte offset 7" in bit_iterator_init call.

Add an unit test that verifies that bit iterator works correctly
with small size bitmaps (like uint32_t).

Change condition a bit hoping that it will calm down the checker.

No functional changes.

It eats way too much memory and is killed by OOM on my laptop,
which has 8 GB of RAM.

For now, source packages are deployed to our repositories with the wrong
version. It is due to the actions/checkout bug with not preserving tag
annotations [1].

This issue was fixed from our side by adding a workaround [2] to the
.github/actions/environment action. But for some reason, invocation of
this action was not added to the 'source.yml' workflow. This patch fixes
that.

[1] https://github.com/actions/checkout/issues/290
[2] https://github.com/tarantool/tarantool/pull/6197

Closes tarantool/tarantool-qa#146

We assume that no one touches the instance's WALs, once it has taken the
wal_dir_lock. This is not the case when upgrading from an old setup
(running tarantool 1.7.3-6 or less). Such nodes either take a lock on
snap dir, which may be different from wal dir, or don't take the lock at
all.

So, it's possible that during upgrade an old node is not stopped
properly before a new node is started in the same data directory.

The old node might even write some extra data to WAL during new node's
startup.

This is obviously bad and leads to multiple issues. For example, new node
might start local recovery, scan the WALs and set replicaset.vclock to
some value {1 : 5}. While the node recovers WALs they are appended by the old
node up to vclock {1 : 10}.
The node finishes local recovery with replicaset vclock {1 : 5}, but
data recovered up to vclock {1 : 10}.

The node will use the now outdated replicaset vclock to subscribe to
remote peers (leading to replication breaking due to duplicate keys
found), to initialize WAL (leading to new xlogs appearing with duplicate
LSNs). There might be a number of other issues we just haven't stumbled
upon.

Let's prevent situations like that and panic as soon as we see that the
initially scanned vclock (replicaset vclock) differs from actually
recovered vclock.

Closes #6709

Patch 19a161b5  removed Ubuntu 20.10 from CI/CD for amd64 only.
Let's do it for arm64 as well.

Ubuntu 20.10 reached end-of-life few months ago,
remove it from CI/CD.

The uri is passed to the accept callback. Currently, it's unused,
but in future we will use uri parameters to configure connections
(e.g. setup encryption).

While we are at it, let's also add a test case for the move constructor.

We are planning to pass some extra connection parameters in uri
(e.g. encryption options).

Before this patch Tarantool http client did not support HTTP/2.
The reasons to enable HTTP/2 support are efficiency offered by
the protocol and potential ability to interact with a GRPC server.
The CMake version requirement is updated from 3.2 to 3.3, because
we need generator expressions in cmake for setting multiple paths
in CMAKE_FIND_ROOT_PATH for nghttp2 support.

Closes #5771

@TarantoolBot document
Title: Now we require CMake 3.3 to build tarantool

In tarantool/doc#2065 we requested to update
the CMake minimum version to 3.2. Now it is time for 3.3.
See details in the linked commit.

Macros SIGSTKSZ used to be an integral constant but
in glibc-2.34 it turned into a runtime function so it
cannot be used as constant known size for arrays anymore.

Beyond this, SIGSTKSZ is not enough for alt. signal stack size
when you use ASAN, so the size was increased.

Closes #6686