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

Closes #5467

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 #5469

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 #5468

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>

GH allows to create custom templates for different kind of issues.
So two separate types of templates added: for feature requests and
for bug reports.

GH also allows to redirect users from a new issue page to external
resources. So requests with commercial support redirected to Tarantool
website and questions redirected to GH Discussions.

Old bug report template has been removed.

Closes #5642

Not all invalid characters were ignored by base64 decoder
causing data corruption and reads beyond decode table
(faults under ASAN).

Added corresponding check into base64 unit test.

Fixes: #5627

* core: remove excess assertion inside memprof
* core: fix resources leak in memory profiler
* misc: fix build with disabled memory profiler

Follows up #5442

Export libcurl's symbols only when they are provided by tarantool
itself: when the library is linked statically into the tarantool's
executable. There is no much sense to export the symbols when we link
against the library dynamically.

Regarding motivation of the change. Since 2.6.0-36-g29ec62891 ('Ensure
all curl symbols are exported') the curl_multi_poll() function is
exported from the tarantool executable. It leads to a failure in
Homebrew's build, because there we link (dynamically) with a system
libcurl. On Mac OS 10.15 it is libcurl 7.64.1, while the function
appears since libcurl 7.66.0. So a linker reports the undefined symbol:
`curl_multi_poll`.

Now the symbols are not exported at dynamic linking with libcurl, so the
linker is happy.

This commit relaxes bounds for dynamic linking, but an attempt to link
with libcurl older than 7.66.0 statically still leads to a linking
failure. The box-tap/gh-5223-curl-exports.test.lua test still fails when
tarantool is linked (dynamically) against an old libcurl.

It looks as the good compromise. When libcurl functionality is provided
by tarantool itself, *all* functions listed in the test are present
(otherwise a linker will complain). But tarantool does not enforce a
newer libcurl version, when it just *uses* this functionality and don't
provide it for modules and stored procedured. It is not tarantool's
responsibility in the case.

We possibly should skip the box-tap/gh-5223-curl-exports.test.lua test
when tarantool is built against libcurl dynamically or revisit the
described approach. I'll leave it as possible follow up activity.

Fixes #5542

Hotfix of 88b76800

Fix an obvious bug - tuple ref/unref manipulation must be done only
 when we handle the primary index. Even code comment states that.

Part of #5628

Now we have a PID 1 zombie reaping problem, when zombie processes
launched in Docker aren't collected by init, how it would be done if we
launch it on a real host.

It is fixed by adding --init option, when a container is created or
started.

Co-authored-by: Artem Starshov <artemreyt@tarantool.org>

Follows up #4983

The general purpose registers were optional earlier
lets make them optional back allowing the code to
be compiled on non x86-64 machines.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>