Using hashes in ExternalProject_Add() [1] allows to avoid extra
downloads on rebuild.

1. https://cmake.org/cmake/help/latest/module/ExternalProject.html

Closes #5761

The same as in previous hotfix (90a72ffd) key_part_def->exclude_null was not
initialized in test unit/luaT_tuple_new.c. So let's set default value of
this field to suppress ASAN warnings.

Closes #5769
Follow-up #4480

After previous patch being applied ASAN detects following behaviour:

box/key_def.c:295:39: runtime error: load of value 77, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior

It happens since field exclude_null in key_part_def was uninitialized
and passed to key_def_new() (see constructAutomaticIndex()). So let's fix
this and set exclude_null field to default value 'false'.

Follow-up #4480

New option "exclude_null=true/false" was introduced.
"is_nullable=true" option will be set automatically.
When it is on, index skips tuples with "null" value of this part.
E.g. index `s:create_index('sk', {parts={{2, 'number', exclude_null=true}}})`
will ignore `{1, null}, {2, null}`, but will not ignore `{null, 1}, {1, 1}`.

Part of #4480

@TarantoolBot document
Title: new option "exclude_null=true/false"
Added new option for index part definition,
that allows index to skip tuples with null at this part.
By default the option is turned off.
When turned on, "is_nullable=true" option will be set automatically.
It can't be turned on for the primary key.
Option can be changed dynamically (in this case index is rebuilt).
Such index does not store filtered tuples at all,
so indexing can be done faster.
SQL: such index is skipped in select statements
unless explicitly specified.

`exclude_null` and `is_nullable` are connected, so
this table describes the result of combining them.

| Exclude NULL/Nullable | False | True |
| ----------------------- | ---------- | -------------- |
| False     |  +     | +      |
| True       | - *   |  + **     |

* is not allowed
** Partial index

Removed definitions of functions with timeout. Now they are used
from separated module process_timeout.lua

Follows up #4983

Functions with timeout transferred to module test/app-tap/lua/process_timeout.lua
for further using in other tests.
(from test/app-tap/gh-4983-tnt-e-assert-false-hangs.test.lua)

Follows up #4983

Set timeout to 60 sec for waiting operations with process,
like in default timeout for `cond_wait` in test-run.
Increasing timeout needed cause tests are failed under high
concurrency occasionally.

Follows up #4983

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.

CMake 3.1 or newer is essential for implementing LuaJIT self-sufficient
testing environment (see more info in the next patch). Unfortunately,
not all distributions provide the required CMake from the repositories.
Here is the actual list of default packages providing CMake for the
distributions that support Tarantool:
| Distro             | CMake version | Repo                |
|--------------------+---------------+---------------------|
| CentOS 6           | 2.8.12        | base                |
| CentOS 7           | 2.8.12        | base                |
| CentOS 8           | 3.11.4        | appstream           |
| Debian Jessie      | 3.0.2         | jessie/main         |
| Debian Stretch     | 3.7.2         | stretch/main        |
| Debian Buster      | 3.13.4        | buster/main         |
| Fedora 28          | 3.14.4        | updates             |
| Fedora 29          | 3.14.5        | updates             |
| Fedora 30          | 3.17.2        | updates             |
| Fedora 31          | 3.17.4        | updates             |
| Fedora 32          | 3.17.4        | updates             |
| FreeBSD 12         | 3.15.5        | default             |
| OSX 14             | 3.19.3        | brew                |
| OSX 15             | 3.19.3        | brew                |
| Ubuntu 14.04       | 2.8.12        | trusty/main         |
| Ubuntu 16.04       | 3.5.1         | xenial-updates/main |
| Ubuntu 18.04       | 3.10.2        | bionic-updates/main |
| Ubuntu 20.04       | 3.16.3        | focal/main          |
| openSUSE Leap 15.1 | 3.10.2        | Main                |
| openSUSE Leap 15.2 | 3.17.0        | Main                |

As one can see, there are no required packages provided by default for
the following distributions: CentOS 6, CentOS 7, Debian Jessie and
Ubuntu 14.04. There are alternative packages (i.e. cmake3) providing a
newer CMake than the default one for the old packages:
| Distro             | CMake3 version  | Repo                    |
|--------------------+-----------------+-------------------------|
| CentOS 6           | 3.6.1           | epel*                   |
| CentOS 7           | 3.17.5          | epel*                   |
| Ubuntu 14.04       | 3.5.1           | trusty-updates/universe |

(*) Unfortunately, I failed to find the way to make rpmbuild install
    and enable EPEL repository prior to the build step. However,
    cmake3 requirement obligues user to enable EPEL by himself,
    otherwise this dependency is left unmet. If there are any issues
    with building an RPM on CentOS 7 please proceed to the docs[1].

So the last problem is Debian Jessie: the required CMake toolchain is
provided neither via the default repository nor via the auxiliary one
(e.g. kinda updates repository like it's done for Ubuntu 14.04). Anyway,
Debian Jessie long term support has reached its EOL[2], so we can freely
drop this distribution from our regular build testing.

[1]: https://www.tarantool.io/en/doc/latest/dev_guide/building_from_source/
[2]: https://www.debian.org/News/2020/20200709



Relates to #4862

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

Building on FreeBSD 12 using VM VBox with commands:

  cmake . && gmake -j

got issue in test build:

  [ 72%] Building C object test/unit/CMakeFiles/swim_proto.test.dir/swim_test_transport.c.o
  /home/vagrant/tnt/test/unit/swim_test_transport.c:55:13: error: incomplete definition of type 'struct sockaddr'
          assert(addr->sa_family == AF_INET);
                 ~~~~^
  /usr/include/assert.h:56:21: note: expanded from macro 'assert'
  #define assert(e)       ((e) ? (void)0 : __assert(__func__, __FILE__, \
                            ^
  /usr/include/netinet/in.h:586:8: note: forward declaration of 'struct sockaddr'
  struct sockaddr;
         ^
  /home/vagrant/tnt/test/unit/swim_test_transport.c:55:28: error: use of undeclared identifier 'AF_INET'
          assert(addr->sa_family == AF_INET);
                                    ^
  2 errors generated.
  gmake[2]: *** [test/unit/CMakeFiles/swim_proto.test.dir/build.make:76: test/unit/CMakeFiles/swim_proto.test.dir/swim_test_transport.c.o] Error 1
  gmake[1]: *** [CMakeFiles/Makefile2:5404: test/unit/CMakeFiles/swim_proto.test.dir/all] Error 2
  gmake: *** [Makefile:152: all] Error 2

To fix the test added headers in it:

  #include <netinet/in.h>
  #include <sys/socket.h>

Closes #5748

Added jobs for testing and deploying Fedora 33 packages.

Added Fedora 33 at update_repo tool to make able to save packages
in S3 buckets.

Closes #5502

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 as already removed at:

  8b08a3ba ("gitlab-ci: remove CentOS 6")

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

Ported source and packages deploy jobs from gitlab-ci to github-ci.

Closes #5662

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

Updated third_party/zstd submodule from v1.3.3 to v1.4.8 version.

Found issue building on Fedora 33:

  third_party/zstd/lib/decompress/zstd_decompress.c: In function ‘ZSTD_findFrameCompressedSize’:
  third_party/zstd/lib/decompress/zstd_decompress.c:1502:18: error: ‘zfh.headerSize’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   1502 |         ip += zfh.headerSize;
        |                  ^

Also found that later releases of third_party/zstd submodule already
fixed it. Decided to bump third_party/zstd submodule from v1.3.3 to
v1.4.8. Added to zstd cmake build rules new files appeared on bumping.

Found that some checking in static-build test exporting symbols like:

  ZSTD_free
  ZSTD_malloc

never were public symbols and should not be tested for presence in the
Tarantool executable, but also these symbols currently outdated and
broke the testing. To avoid of it these symbols removed from test.

Needed for #5502
Closes #5697

Closes #5465

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Part of #5442

Reviewed-by: Sergey Ostanevich <sergos@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

Closes #5736

Closes #5650

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5458

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Update the test-run submodule with updating its tarantool-python
submodule with the Response.__str__() change, which unifies behaviour
between Python 2 and Python 3. We lean on this in the
box-py/call.test.py test. See more in [1].

Updated the box-py/iproto.test.py test, because it is confused by the
new IPROTO_SQL_INFO_* constants, introduced in the tarantool-python
connector in [2].

Part of https://github.com/tarantool/test-run/issues/20
Part of #5652

[1]: https://github.com/tarantool/test-run/pull/264
[2]: https://github.com/tarantool/tarantool-python/commit/9d3573e36199ee5ebc360f9017190ada9726bb23

Closes #5169

(cherry picked from commit a661bef70d4ff2ba511c6e6ea71e95c6f50beb49)

Closes #5460

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5466

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Follows up #5457

Follows up #5455

Found that artifacts uses storage space which is limited to 0,5 GiB.
To avoid of lack of the space there decided to decrease the retention
days option for artifacts from default 90 days to 21 days (3 weeks).

OSX 13 was tested for homebrew commit criteria. But a month ago
criteria list changed and OSX 13 was removed [1]. So we don't
need it any more in our commit criteria - removing.

[1] - https://github.com/Homebrew/homebrew-core/actions/runs/465259174

Found issue:

  pkg: No packages available to install matching 'py27-yaml' have been found in the repositories
  pkg: No packages available to install matching 'py27-gevent' have been found in the repositories

Happened at .travis.mk file target:

  deps_freebsd:
          sudo pkg install -y git cmake gmake icu libiconv \
                  python27 py27-yaml py27-six py27-gevent \
                  autoconf automake libtool

It happened becasue Python 2 is end of life and all OS distributions
changed to use Python 3. Also all repositories removed its copies of
the Python 2 packages.

Due to FreeBSD 12 is testing using VBox VM image which already has
all the needed Python 2 packages, the current fix is to change the
gitlab-ci job to use instead of 'test_freebsd' target, which calls
'deps_freebsd' target with calls to install Python 2 packages, use
'test_freebsd_no_deps' target without it. We really won't need these
packages feather due to next update of these gitlab-ci jobs will be
change of make targets to use Python 3 packages instead of Python 2.

Closes tarantool/tarantool-qa#4

Found issues building on Fedora 33:

  test/unit/fiber_channel.cc: In function ‘fiber_channel_basic’:
  test/unit/fiber_channel.cc:40:2: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     40 |  ok(ptr == &dummy, "fiber_channel_get()");
        |  ^
  test/unit/fiber_channel.cc:37:8: note: ‘ptr’ was declared here
     37 |  void *ptr;
        |        ^

  test/unit/fiber_channel.cc: In function ‘fiber_channel_get’:
  test/unit/fiber_channel.cc:63:2: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     63 |  ok(ptr == &dummy, "fiber_channel_get(0)");
        |  ^
  test/unit/fiber_channel.cc:61:8: note: ‘ptr’ was declared here
     61 |  void *ptr;
        |        ^

To fix the issue set ptr to NULL during initialization.

Needed for #5502
Part of #5697

Closes #5457

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5456

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5455

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

In a commit "httpc: temporary disable redirecting test case"
(4cc6978a) a set of testcases
has been disabled while the bug #4180 is open.
Right now bug is closed so it is a time to enable testcases back.

Follows up: #4180

TL;DR httpd.py warns that port is busy when restart server. With socket
option SO_REUSEADDR it allows to restart httpd.py without problem.

Socket option SO_REUSEADDR tells the kernel that even if this port is
busy, go ahead and reuse it anyway. If it is busy, but with another
state, you will still get an address already in use error. It is useful
if your server has been shut down, and then restarted right away while
sockets are still active on its port.

Set correct encoding on opening file.

Follows up: #5538

Pass http body as byte string, define string literals correctly
and make items() iterable.

Follows up: #5538