Make able to save packages in S3 buckets.

Closes: #6074

Make able to save packages in S3 buckets.

Closes: #5825

Make able to save packages in S3 buckets.

Closes: #5824

Script used to run Jepsen tests uses Terraform to prepare test environment.
When I made this script I had a wrong assumption about working directory
used by Terraform. Due to this sometimes job with Jepsen tests
failed on cleanup with message:

```
Error: Could not load plugin

Plugin reinitialization required. Please run "terraform init".

Plugins are external binaries that Terraform uses to access and manipulate
resources. The configuration provided requires plugins which can't be located,
don't satisfy the version constraints, or are otherwise incompatible.

Terraform automatically discovers provider requirements from your
configuration, including providers used in child modules. To see the
requirements and constraints, run "terraform providers".

Failed to instantiate provider
"registry.terraform.io/terraform-providers/openstack" to obtain schema:
unknown provider "registry.terraform.io/terraform-providers/openstack"
```

Terraform documentation describes how Terraform uses working directories [1]
and there are at least to ways to resolve an issue. First one is using always
one directory before running terraform subcommands. Second one is using option
`-chdir` in all terraform commands [2].

1. https://www.terraform.io/docs/cli/init/index.html
2. https://www.terraform.io/docs/cli/commands/index.html#switching-working-directory-with-chdir

Closes #6089

This patch introduces two scripts to ease crash artefacts collecting and
loading for postmortem analysis:

* tarabrt.sh - the tool collecting a tarball with the crash artefacts
  the right way: the coredump with the binary, all loaded shared libs,
  Tarantool version (this is a separate exercise to get it from the
  binary built with -O2). Besides, the tarball has a unified layout, so
  it can be easily processed with the second script:
  - /coredump - core dump file on the root level
  - /binary - tarantool executable on the root level
  - /version - plain text file on the root level with
    `tarantool --version` output
  - /checklist - plain text file on the root level with the list of the
    collected entities
  - /etc/os-release - the plain text file containing operating system
    identification data
  - all shared libraries used by the crashed instance - their layout
    respects the one on the host machine, so they can be easily loaded
    with the following gdb command: set sysroot $(realpath .)

  The script can be easily used either manually or via
  kernel.core_pattern variable.

* gdb.sh - the auxiliary script originally written by @Totktonada, but
  needed to be adjusted to the crash artefacts layout every time. Since
  there is a unified layout, the original script is enhanced a bit to
  automatically load the coredump via gdb the right way.

Closes #5569

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
Reviewed-by: Sergey Bronnikov <sergeyb@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

Enabling ubuntu-20.04 hosts for packaging workflows found that DEB
package Github Actions workflows do not need to install createrepo
tool. Also found that createrepo is not ready for ubuntu-20.04 as
described in (till ubuntu-21.04 where it is available as the new
version of this tool named as 'createrepo_c' as DEB package):

  3a7c2102 ('github-ci: ubuntu-20.04 misses createrepo package')

To fix it added 'createrepo_c' build and installation from sources
and changed in update_repo tool 'createrepo' tool to 'createrepo_c'.
This patch is needed to use these workflows on self-hosted runners
which run under ubuntu-20.04 by default for now.

Also checking the patch on ubuntu-20.04 hosts got the following issue:

  Regenerated DEB file: pool/xenial/main/t/tarantool/tarantool-common_2.8.0.185.g4c3e0eb-1_all.deb

  <botocore.awsrequest.AWSRequest object at 0x7f7998a4ca90>

  <botocore.awsrequest.AWSRequest object at 0x7f627d965070>
  make: *** [.gitlab.mk:131: deploy] Error 255
  Error: Process completed with exit code 2.

Found that there is already issue exists in Github Actions on it [1].
Provided solution to setup AWS region in environment helped to
workaround the issue [2].

Closes tarantool/tarantool-qa#110
Closes tarantool/tarantool-qa#111

[1]: https://github.com/aws/aws-cli/issues/5234
[2]: https://github.com/aws/aws-cli/issues/5234#issuecomment-635459464

Found that running package removement command from S3:

  ./tools/update_repo.sh -o=fedora -d=30 -b=s3://tarantool_repo/live/1.10 -r=tarantool-1.10.9.108

it searched to remove:

  Searching to remove: s3://tarantool_repo/live/1.10/fedora/30/SRPMS/Packages/tarantool-1.10.9.108-1.fedora30.src.rpm

while it had to be:

  Searching to remove: s3://tarantool_repo/live/1.10/fedora/30/SRPMS/Packages/tarantool-1.10.9.108-1.fc30.src.rpm

where 'fc30' had to be instead of 'fedora30'. This patch fixes it.

- install python3 on mac machines
- run test-run without specifying path to python interpreter
- get rid our own tarantool brew-tap that depends on Python 2

Part of #5652

Found issues and resolved:

- Added '$PROJECT_BINARY_DIR/build/' path creation before use.

- Set always ssh-agent restart before add new SSH key, because
  found that in some situations it may fail to add w/o it.

- Found mistake in TF_VAR_id variable setup, inverted ${CI_JOB_ID}
  variable check for it.

Also made improvements in script:

- Added all needed checks for all externally set mandatory variables.

- Added usage message with the list of mandatory and optional variables.

- Added comments to all script steps.

- Added step with checking nodes that they are reachable by SSH.

See https://github.com/tarantool/tarantool/discussions/5634

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

Added package workflow to github actions. Set deployment of the
packages for the master branch and tags.

Closes #5638

It was added Fedora 32 gitlab-ci packaging job in commit:
  507c47f7a829581cc53ba3c4bd6a5191d088cdf ("gitlab-ci: add packaging for Fedora 32")

but also it had to be enabled in update_repo tool to make able to save
packages in S3 buckets.

Follows up #4966

Implemented ability to remove opensuse-leap OS packages.

Updated help message on remove option.

Added message which file to remove to be sure that the needed files
were searched to remove.

Found that Sources file destroys when module uploaded without sources.
Also found that it could happen for Packages file on modules uploading
without binaries. To fix it was added additional its downloading from
S3 if in modules it was not updated and routine was not used.

To run Jepsen tests in different configurations we need to parametrize run
script by options, so lein options and number of nodes passed with environment
variables. By default script runs testing with Tarantool built from latest
commit.

Added these configurations:

- single instance
- single instance with enabled TXM
- cluster with enabled Raft
- cluster with enabled Raft and TXM

Closes #5437

Main script that handle creation of set of virtual machines
using Terraform, setup for remote connection, running
Jepsen tests and teardown test environment.

Part of #5277

On running update_repo tool with the given option to delete some RPMs
need to remove all files found by this given pattern. The loop checking
metadata deletes files, but only which were presented in it. However
it is possible that some broken update left orphan files: they are
present in the storage, but does not mentioned in the metadata.

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

Fixed unbound variables at packaging tool update_repo.sh.

Closes #5114

Found that modules may have only sources packages w/o binaries
packages. Script updated to be able to work with only binaries
either sources RPM packages. The same fix was already done for
DEB packages at commit 4527a4da.

Close #4839

Found that in commit 'travis-ci/gitlab-ci: add Ubuntu Focal 20.04'
forgot to add Ubuntu Focal to the list of the available Ubuntu
distributions in the script for saving built packages at S3.

Follow up #4863

Added ability to remove given in options package from S3. TO remove the
needed package need to set '-r=<package name with version>' option,
like:
  ./tools/update_repo.sh -o=<OS> -d=<DIST> -b=<S3 repo> \
    -r=tarantool-2.2.2.0
it will remove all found appropriate source and binaries packages from
the given S3 repository, also the meta files will be corrected there.

Close #4839

Added instructions on 'product' option with examples.

Part of #4839

Found that modules may have only binaries packages w/o sources
packages. Script changed to be able to work with only binaries
either sources packages.

Part of #4839

Added cleanup functionality for the meta files.
Script may have the following situations:

 - package files removed at S3, but it still registered:
   Script stores and registers the new packages at S3 and
   removes all the other registered blocks for the sames
   files in meta files.

 - package files already exists at S3 with the same hashes:
   Script passes it with warning message.

 - package files already exists at S3 with the old hashes:
   Script fails w/o force flag, otherwise it stores and
   registers the new packages at S3 and removes all the other
   registered blocks for the sames files in meta files.

Added '-s|skip_errors' option flag to skip errors on changed
packages to avoid of exits on script run.

Part of #4839

Fixed OSX host setup for Tarantool build:
- set brew installation from Homebrew repository instructions;
- set in use Python 2 latest commit from tapped local formula,
  since Python 2 is EOL, also removed extra pip installation with
  get-pip script, because tapped formula installs pip itself.
  python@2 was deleted from homebrew/core in commit 028f11f9e:
    python@2: delete (https://github.com/Homebrew/homebrew-core/issues/49796)
    EOL 1 January 2020.
  Tapped formula created from the latest formula before its removal:
    git -C "$(brew --repo homebrew/core)" show 028f11f9e^:Formula/python@2.rb
- added upgrade packages call to avoid of fails on already
  installed packages, but with previous version;
- fixed the gitlab-ci configuration for sudo on testing hosts and removed pip
  option '--user' to avoid of use the users paths with special setup for it.

Fixed OSX host setup for Tarantool test:
- set maximum processes limit value to 2500 for testing process;
- new Mac machines are going to be added into CI and usernames on them
  are long according to internal policies. It makes a home directory to
  be long too and so a path to a unix socket created during testing can
  be longer then UNIX_PATH_MAX=108 constant which is described as issue
    https://github.com/tarantool/tarantool/issues/4634
  To avoid of it the short working directory for testing set by option:
    --vardir /tmp/tnt

Our S3 based repositories now reflect packagecloud.io repositories
structure.

It will allow us to migrate from packagecloud.io w/o much complicating
redirection rules on a web server serving download.tarantool.org.

Deploy source packages (*.src.rpm) into separate 'SRPM' repository
like packagecloud.io does.

Changed repository signing key from its subkey to public and moved it
to gitlab-ci environment.

Follows up #3380

Found that on 19.02.2020 APT repositories with packages
for Ubuntu 18.10 Cosmic were removed from Ubuntu archive:

 E: The repository 'http://security.ubuntu.com/ubuntu cosmic-security Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic-updates Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic-backports Release' does not have a Release file.

Also found the half a year old message about Ubuntu 18.10
Cosmic EOL:
 https://fridge.ubuntu.com/2019/07/19/ubuntu-18-10-cosmic-cuttlefish-end-of-life-reached-on-july-18-2019/

Removed the Ubuntu 18.10 Cosmic from gitlab-ci and
travis-ci testings.

We're going to use S3 compatible storage for Deb and RPM repositories
instead of packagecloud.io service. The main reason is that
packagecloud.io provides a limited amount of storage, which is not
enough for keeping all packages (w/o regular pruning of old versions).

Note: At the moment packages are still pushed to packagecloud.io from
Travis-CI. Disabling this is out of scope of this patch.

This patch implements saving of packages on an S3 compatible storage and
regeneration of a repository metadata.

The layout is a bit different from one we have on packagecloud.io.

packagecloud.io:

 | - 1.10
 | - 2.1
 | - 2.2
 | - ...

S3 compatible storage:

 | - live
 |   - 1.10
 |   - 2.1
 |   - 2.2
 |   - ...
 | - release
 |   - 1.10
 |   - 2.1
 |   - 2.2
 |   - ...

Both 'live' and 'release' repositories track release branches (named as
<major>.<minor>) and master branch. The difference is that 'live' is
updated on every push, but 'release' is only for tagged versions
(<major>.<minor>.<patch>.0).

Packages are also built on '*-full-ci' branches, but only for testing
purposes: they don't pushed anywhere.

The core logic is in the tools/update_repo.sh script, which implements
the following flow:

- create metadata for new packages
- fetch relevant metadata from the S3 storage
- push new packages to the S3 storage
- merge and push the updated metadata to the S3 storage

The script uses 'createrepo' for RPM repositories and 'reprepro' for Deb
repositories.

Closes #3380