Tests were turned off from arm workflows according to instability.

Needed for #6222

The reason of the update is to protect us against possible MITM attack
from a malicious HTTPS proxy server with trusted certificate when TLS
1.3 is used (CVE-2021-22890, [1]). libcurl versions prior to 7.76.0 can
skip a TLS handshake with a target host in this circumstances.

Other vulnerabilities fixed in the (7.71.1; 7.76.0] version range do not
look relevant to our built-in http client. See [2] for the full list.

The CMake version requirement is updated from 3.1 to 3.2, because curl's
CMakeLists.txt has the following clause at beginning:

 | cmake_minimum_required(VERSION 3.2...3.16 FATAL_ERROR)

(It was there in vanilla curl 7.71.1 too and we had to remove it in
order to support CMake 2. Now we don't support CMake 2, so it is good
time to get rid of the extra patch upward vanilla curl repository.)

According to the CMake versions table in
8a7702b1 ('github-ci: purge Debian
Jessie from CI'), CMake 3.2+ is available on all supported OSes.

[1]: https://curl.se/docs/CVE-2021-22890.html
[2]: https://curl.se/docs/vulnerabilities.html

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

In https://github.com/tarantool/doc/issues/1780 we requested to update
the CMake minimum version to 3.1. Now it is time for 3.2. See details in
the linked commit.

Please, update the 'Building from source' manual.

Ship libcurl headers to system path "${PREFIX}/include/tarantool"
in the case of libcurl included as bundled library or static
build. It is needed to use SMTP client with tarantool's libcurl
instead of system libcurl.

See related issue: https://github.com/tarantool/smtp/issues/24

Closes #4559

Fix package names with Python modules on Centos 7, OpenSUSE, Fedora.
All supported RPM-based distributives (Fedora 33, Fedora 32, OpenSUSE 15.2,
OpenSUSE 15.1, CentOS 8) contains python3, python3-six and python3-gevent
packages except CentOS 7 and CentOS 6.
We don't run tests when make packages for CentOS 6. For CentOS 7 we create
our own RPM packages for Python3 dependencies.

Patch unblocks regression testing on Fedora 33.

Part of #5652
Closes tarantool/tarantool-qa#17

LuaJIT submodule is bumped to introduce the following changes:
* test: run luacheck static analysis via CMake
* test: fix warnings found with luacheck in misclib*
* test: run LuaJIT tests via CMake
* build: replace GNU Make with CMake
* build: preserve the original build system

Since LuaJIT build system is ported to CMake in scope of the changeset
mentioned above, the module building the LuaJIT bundled in Tarantool is
completely reworked. There is no option to build Tarantool against
another prebuilt LuaJIT due to a91962c0
('Until Bug#962848 is fixed, don't try to compile with external
LuaJIT'), so all redundant options defining the libluajit to be used in
Tarantool are dropped with the related auxiliary files.

To run LuaJIT related tests or static analysis for Lua files within
LuaJIT repository, <LuaJIT-test> and <LuaJIT-luacheck> targets are used
respectively as a dependency of the corresponding Tarantool targets.

As an additional dependency to run LuaJIT tests, prove[1] utility is
required, so the necessary binary packages are added to the lists with
build requirements.

[1]: https://metacpan.org/pod/TAP::Harness#prove



Closes #4862
Closes #5470
Closes #5631

Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Reviewed-by: Timur Safin <tsafin@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

In scope of implementing self-sufficient testing environment LuaJIT
build system is partially ported to CMake. While integrating the new
build system with Tarantool it was found (on practice of course) that
using generator expressions[1] in target DEPENDS section is introduced
only in CMake 3.1[2]. This CMake feature is used to pass so called
"LuaJIT binary" to be used in LuaJIT tests, so one can run the same
testing machinery with both Tarantool and LuaJIT with no changes in it.

[1]: https://cmake.org/cmake/help/v3.1/manual/cmake-generator-expressions.7.html
[2]: https://cmake.org/cmake/help/latest/release/3.1.html#commands



Relates to #4862

Reviewed-by: Alexander V. Tikhonov <avtikhon@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

@TarantoolBot document
Title: Update CMake minimum required version in build documentation

This commit updates the CMake minimum required version to be used in
Tarantool build infrastructure. However, one can build Tarantool from
sources and the required toolchain list should be updated. CMake minimum
required version is 3.1 since this commit. See the commit message for
more info.

Since Python 2 was deprecated then new OS do not have repositories
with its packages. It is not good way to create all these packages
manually and store it as backported. Let's wait when Python 3 will
be used for testing and for now the testing disabled for Fedora 33
packaging.

Also found that %cmake macros used in build spec was changed - new
option was added:

  -B x86_64-redhat-linux-gnu

It changed the build path and broke the build, to fix it these
options was additionally locally reset to:

  -B .

Found that LTO was set by default in Fedora 33, check

  /usr/lib/rpm/redhat/macros

    # LTO is the default in Fedora.
    #   "%define _lto_cflags %{nil}"  to opt out
    #
    # We currently have -ffat-lto-objects turned on out of an abundance of
    # caution.  To remove it we need to do a check of the installed .o/.a files
    # to verify they have real sections/symbols after LTO stripping.  That
    # way we can detect installing an unusable .o/.a file.  This is on the TODO
    # list for F34.
    %_gcc_lto_cflags        -flto=auto -ffat-lto-objects
    %_clang_lto_cflags      -flto
    %_lto_cflags            %{expand:%%{_%{toolchain}_lto_cflags}}

    %_general_options       -O2 %{?_lto_cflags} -fexceptions -g -grecord-gcc-switches -pipe

and build issues occured:

  /build/usr/src/debug/tarantool-2.8.0.2/src/lib/core/reflection.h:124:33: warning: type of ‘METHODS_SENTINEL’ does not match original declaration [-Wlto-type-mismatch]
    124 | extern const struct method_info METHODS_SENTINEL;
        |                                 ^
  /build/usr/src/debug/tarantool-2.8.0.2/src/lib/core/reflection.c:35:26: note: ‘METHODS_SENTINEL’ was previously declared here
     35 | const struct method_info METHODS_SENTINEL = {
        |                          ^

it was fixed as was suggested in 1st way of [1][2]. This warning was
disabled in commit:

  f9e28ce4 ("Add LTO support")

with cmake flag:

  -D_ENABLE_LTO=ON

so added this flag to cmake RPM spec build flags for Fedora 33 and its
later versions.

Needed for #5502
Needed for #5697

[1] - https://github.com/tarantool/tarantool/issues/5697#issuecomment-759409465
[2] - https://github.com/tarantool/tarantool/pull/5707#discussion_r561072044

Removed CentOS 6 from packages build jobs, due to it reached
end of lifetime [1].

[1] - https://wiki.centos.org/About/Product

After cURL was changed to use cmake in commit

  2b076019 ('build: enable cmake in curl build')

there is no need to set dependencies to autotools. So removed it from:

  - rpm build spec for packages builds
  - deb build control for packages builds
  - OSX build targets
  - static OSX build target
  - freebsd VBOX VM image setup

Enabled replication/ suite in packaging testing. After major number of
issues were resolved in test-run tool and in frequently failing flaky
tests replication/ suite can be tested within packaging testing.

Closes #4798

Removed obvious part in rpm spec for Travis-CI, due to it is no
longer in use.

---- Comments from @Totktonada ----

This change is a kind of revertion of the commit
d48406d5 ('test: add more tests to
packaging testing'), which did close #4599.

Here I described the story, why the change was made and why it is
reverted now.

We run testing during an RPM package build: it may catch some
distribution specific problem. We had reduced quantity of tests and
single thread tests execution to keep the testing stable and don't break
packages build and deployment due to known fragile tests.

Our CI had to use Travis CI, but we were in transition to GitLab CI to
use our own machines and don't reach Travis CI limit with five jobs
running in parallel.

We moved package builds to GitLab CI, but kept build+deploy jobs on
Travis CI for a while: GitLab CI was the new for us and we wanted to do
this transition smoothly for users of our APT / YUM repositories.

After enabling packages building on GitLab CI, we wanted to enable more
tests (to catch more problems) and wanted to enable parallel execution
of tests to speed up testing (and reduce amount of time a developer wait
for results).

We observed that if we'll enable more tests and parallel execution on
Travis CI, the testing results will become much less stable and so we'll
often have holes in deployed packages and red CI.

So, we decided to keep the old way testing on Travis CI and perform all
changes (more tests, more parallelism) only for GitLab CI.

We had a guess that we have enough machine resources and will able to do
some load balancing to overcome flaky fails on our own machines, but in
fact we picked up another approach later (see below).

That's all story behind #4599. What changes from those days?

We moved deployment jobs to GitLab CI[^1] and now we completely disabled
Travis CI (see #4410 and #4894). All jobs were moved either to GitLab CI
or right to GitHub Actions[^2].

We revisited our approach to improve stability of testing. Attemps to do
some load balancing together with attempts to keep not-so-large
execution time were failed. We should increase parallelism for speed,
but decrease it for stability at the same time. There is no optimal
balance.

So we decided to track flaky fails in the issue tracker and restart a
test after a known fail (see details in [1]). This way we don't need to
exclude tests and disable parallelism in order to get the stable and
fast testing[^3]. At least in theory. We're on the way to verify this
guess, but hopefully we'll stick with some adequate defaults that will
work everywhere[^4].

To sum up, there are several reasons to remove the old workaround, which
was implemented in the scope of #4599: no Travis CI, no foreseeable
reasons to exclude tests and reduce parallelism depending on a CI
provider.

Footnotes:

[^1]: This is simplification. Travis CI deployment jobs were not moved
      as is. GitLab CI jobs push packages to the new repositories
      backend (#3380). Travis CI jobs were disabled later (as part of
      #4947), after proofs that the new infrastructure works fine.
      However this is the another story.

[^2]: Now we're going to use GitHub Actions for all jobs, mainly because
      GitLab CI is poorly integrated with GitHub pull requests (when
      source branch is in a forked repository).

[^3]: Some work toward this direction still to be done:

      First, 'replication' test suite still excluded from the testing
      under RPM package build. It seems, we should just enable it back,
      it is tracked by #4798.

      Second, there is the issue [2] to get rid of ancient traces of the
      old attempts to keep the testing stable (from test-run side).
      It'll give us more parallelism in testing.

[^4]: Of course, we perform investigations of flaky fails and fix code
      and testing problems it feeds to us. However it appears to be the
      long activity.

References:

[1]: https://github.com/tarantool/test-run/pull/217
[2]: https://github.com/tarantool/test-run/issues/251

Added ENABLE_WERROR flag to build options to enable Werror.

Part of #4941

Since LuaJIT provides extended LuaC API introduced in the scope of
5a61e1ab54b5c66bfebd836db1ac47996611e065 ('misc: add C and Lua API for
platform metrics') corresponding header should be provided along with
other Tarantool development files.

Follows up #5187

Implemented openSUSE packages build with testing for images:
opensuse-leap:15.[0-2]

Added %{sle_version} checks in Tarantool spec file according to
https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macros

Added opensuse-leap of 15.1 and 15.2 versions to Gitlab-CI packages
building/deploing jobs.

Closes #4562

Changed number of tests to packaging testing jobs from
suites: "unit/ app/ app-tap/ box/ box-tap/ engine/ vinyl/",
to all suites except 'replication/' suite which has special
issue for it's enabling:
  https://github.com/tarantool/tarantool/issues/4798
Also added testing to the all available packing jobs except
'CentOS 6'.

Removed test-run option that run testing inline to be
able to run it in parallel. Also changed 'test-run' to
'make test-force' command.

Closes #4599

Found that issues #1227 and #1322 were closed, returned
the tests blocked by it into the testing.

Part of #4599

Tarantool packages build scenario at rpm/tarantool.spec
installs Python packages for Tarantool testing. In some
latest OS like Fedora 32 old Python packages based on
Python 2 version were deprecated and changed to Python 3.
Currently Tarantool testing based on Python 2 which
packages stored at local backport repository and it
should be used from there calling it as python2-* packages.

Issue:
...
No matching package to install: 'python-yaml >= 3.0.9'
...
Not all dependencies satisfied
Error: Some packages could not be found.

Needed for #4599
Closes #4965

Added build + test jobs in GitLab-CI and build + test + deploy jobs on
Travis-CI for Fedora 31.

Updated testing dependencies in the RPM spec to follow the new Python 2
package naming scheme that was introduced in Fedora 31: it uses
python2-' prefix rather then 'python-'.

Fedora 31 does not provide python2-gevent and python2-greenlet packages,
so they were pushed to https://packagecloud.io/packpack/backports
repository. This repository is enabled in our build image
(packpack/packpack:fedora-31) by default. Those dependencies are build-time,
so nothing was changed for a user. The source RPM packages were gathered
from https://rpms.remirepo.net/rpmphp/

.

Closes #4612

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>

Added build + test jobs in GitLab-CI and build + test + deploy jobs on
Travis-CI for CentOS 8.

Updated testing dependencies in the RPM spec to follow the new Python 2
package naming scheme that was introduced in CentOS 8: it uses
'python2-' prefix rather then 'python-'.

CentOS 8 does not provide python2-gevent and python2-greenlet packages,
so they were pushed to https://packagecloud.io/packpack/backports
repository. This repository is enabled in our build image
(packpack/packpack:el-8) by default. Those dependencies are build-time,
so nothing was changed for a user. The source RPM packages were gathered
from https://cbs.centos.org

.

Disabled app-tap/pwd.test.lua on CentOS 8 due to systemd-nss issue,
which was not worked around properly. Filed #4592 to resolved it in the
future.

Eliminated libunwind runtime dependency (and libunwind-devel build
dependency) on CentOS 8, because the base system does not provide it.
fiber.info() backtraces and printing of a backtrace after a crash will
not be available on this system. Hopefully we'll fix it in the future,
filed #4611 on this.

Closes #4543

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

After we started using bundled version of libyaml by default (see commit
47b91e90), we can remove it from
building dependencies for RPM and DEB packages.

Closes #4442

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>

Hold libcurl-7.65.3. This version is not affected by the following
issues:

* #4180 ('httpc: redirects are broken with libcurl-7.30 and older');
* #4389 ('libcurl memory leak');
* #4397 ('HTTPS seem to be unstable').

After this patch libcurl will be statically linked when
ENABLE_BUNDLED_LIBCURL option is set. This option is set by default.

Closes #4318

@TarantoolBot document
Title: Tarantool dependency list was changed

* Added build dependencies: autoconf, automake, libtool, zlib-devel
  (zlib1g-dev on Debian).
* Added runtime dependencies: zlib (zlib1g on Debian).
* Removed build dependencies: libcurl-devel (libcurl4-openssl-dev on
  Debian).
* Removed runtime dependencies: curl.

The reason is that now we use compiled-in libcurl: so we don't depend on
a system libcurl, but inherit its dependencies.

After we fixed bundled libyaml to correctly print 4-byte Unicode
characters, it is no longer compatible with the upstream version, so
enable building with bundled libyaml for every platform.
This way the tests will pass.

Follow-up #4090

Added --force flag to travis-ci jobs not to stop on failed tests.
Due to any found failed test breaks the testing it masks the other
fails and in the following ways it's not good:
- flaky test masks real problem
- release testing needs overall result to fix it fast
- parallel testing may produce flaky test

Close: #4131

This reverts commit c2de45c4.

Not needed anymore as the DDL bug it was supposed to work around has
been finally fixed.

Follow-up #3420

Until the bug in #3420 is fixed

The -j -1 used to legacy consistent mode. Reducing the number of jobs
to one by switching to -j 1, uses same part of the code as in parallel
mode. The code in parallel mode kills hung tests.

Part of https://github.com/tarantool/test-run/issues/106

* remove obsolete comments from recovery.cc
* update example lua

Remove libbfd from dependencies and use libunwind for stack traces.

Closes #2103

LuaRocks requires openssl and curl in order to download
manifest from rocks.tarantool.org.

Fixes #2612

Usage:

    tarantoolctl rocks install ROCK - install a rock
    tarantoolctl rocks remove ROCK - remove a rock
    tarantoolctl rocks show ROCK - show information about an installed rock
    tarantoolctl rocks search PATTERN - search repository for rocks
    tarantoolctl rocks list - list all installed rocks

There are no other commands, options, configuration files. Our official
repository (http://rocks.tarantool.org) works out of the box. All rocks
are installed to ${PWD}/.rocks directory to support separate rocks trees
per project, as proposed by #2067. Rockspec can use "tarantool >= 1.7.x"
inside dependencies = {} block to depend on a specific Tarantool version.

LuaRocks has been slightly hacked to support custom configuration
via site_config.lua. There are no other changes in the upstream code.
It is not a fork and it isn't going to be a fork. All formats, layouts
and rockspecs are 100% compatible with the upstream LuaRocks 2017-07-10.

This feature intentionally doesn't have CMake option to disable it,
because it should be provided on all available platforms out of the box.

Other changes:

 * Add ${PWD}/.rocks to default package.path/package.cpath
 * Hack tarantoolctl to display subcommands in --help.
   Currently command line arguments handling are not perfect, but
   it can be fixed only by a new argparse implementation.

Closes #2067

Inpspired by tarantool/curl module by Vasiliy Soshnikov.
Reviewed and refactored by Roman Tsisyk.

Closes #2083

Original behavior can be enable with `./test-run -j -1`

See https://github.com/tarantool/test-run/issues/56

This patch removes following source files regeneration:
  1. keywordhash.h
  2. opcodes.[hc]
  3. parse.[hc]
  4. sqlite3.h
adding them to the source tree.

To re-generate them (p.p. 1-3) one must pass
-DSQL_MAINTAINER_MODE=ON option to cmake. Files will be
copied to source tree automatically iif actual difference will
be detected.

As far we don't need such platform variety - remove sqlite3.h
re-generation at all.
Remove TCL script responsible for generation and template header
as well.

Compilation of auxilary SQL tools was also moved under this option:
  1. Lemon parser
  2. mkkeywordhash
since they redundant in non-maintainer mode.

Finally it removes dependency on TCL from all Tarantool package
variants.

Remove sqliteConfig.h, we don't use it.

SQLite uses TCL shell to generate common headers.
Add dependency in Travis to TCL shell for linux targets.
OSX comes with TCL pre-installed - no need to add dependency.

	* .travis.mk (deps_linux): Add tcl.

sql: Add dependency to TCL in packages.

As far as SQLite sources depend on TCLsh we need to
add dependency to TCL in package info.

	* debian/control: Add dependency on TCL.
	* rpm/tarantool.spec: Ditto.
	* snapcraft.yaml: Ditto.

sql: Avoid multiline string to satisfy older cmake

RHEL uses some old cmake which doesn't work with long string
which span over few lines w/ '\' terminator. Make it single line.

	* src/box/CMakeLists.txt (set_source_files_properties): Use
	single line instead of vreaks w/ '\'.

Sophia was an experimental storage engine in 1.6.x.
Please use 'vinyl' engine in Tarantool 1.7 instead.

Closes #2040

Totally disable /usr/lib/rpm/brp-strip-* scripts on all
versions of rpmbuild.

Fixes #1901

* Don't start tarantool on install
* Don't restart tarantool on upgrade

Fix #2053