Currently `make` in `static-build` doesn't rebuild Tarantool when source
files are changed. Fix this by setting BUILD_ALWAYS option, which forces
rescan for changes of the external project [1]:

> This option is not normally needed unless developers are expected to
> modify something the external project's build depends on in a way that
> is not detectable via the step target dependencies (e.g. SOURCE_DIR is
> used without a download method and developers might modify the sources
> in SOURCE_DIR).

It is available since CMake 3.1, so update cmake_minimum_required, as we
already require it (fa8d70ca).

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

Part of #7536

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=minor

Commit ed16c1e5 ("build: fix bundled
libcurl and c-ares build on OS X") fixed building libcurl with ares by
adding a dependency on libresolv for Mac OS X. It was forgotten to add
libresolv to check-dependencies exceptions for static build. Do this now.

NO_DOC=CI stuff
NO_TEST=CI stuff
NO_CHANGELOG=CI stuff

NO_DOC=build
NO_TEST=build

The static build for Linux leans on glibc provided iconv functions. On
Mac OS it links GNU libiconv statically. This patch updates the libiconv
version from 1.16 (released in 2019) to 1.17 (released in 2022).

It is just regular maintenance update. No behaviour changes are
expected. The libiconv 1.17 changelog (see the NEWS file in the archive)
does not mention anything that may have influence on behavior of
tarantool's iconv built-in module.

NO_DOC=no user-visible changes
NO_TEST=no user-visible changes
NO_CHANGELOG=no user-visible changes

Without `-isysroot <SDK_PATH>` the build fails:

```
/Library/Developer/CommandLineTools/usr/bin/make[4]: Making `all' in   \
    `makeconv'
/Library/Developer/CommandLineTools/usr/bin/c++ -O2 -W -Wall -pedantic \
    -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11          \
    -Wno-ambiguous-reversed-operator     -o ../../bin/makeconv         \
    gencnvex.o genmbcs.o makeconv.o ucnvstat.o -L../../lib -licutu     \
    -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata         \
    -licudata -lpthread -lm
ld: library not found for -lpthread
clang: error: linker command failed with exit code 1 (use -v to see    \
    invocation)
```

ICU is written on C++, so we should pass `CXXFLAGS`, not only `CFLAGS`.

Note: `CPPFLAGS` stands for C preprocessor flags, not C++ flags.

Fixes #7459

NO_DOC=it fixes a build failure for one of build types, nothing to
       document
NO_TEST=it will be tested in a next commit by enabling corresponding
        GitHub Action workflow

Just regular update to bring readline security fixes into tarantool.

Added a patch to fix file descriptor leak with zero-length history file.

Source of patch: https://ftp.gnu.org/gnu/readline/readline-8.0-patches/
Announcement: https://lists.gnu.org/archive/html/bug-readline/2019-08/msg00004.html

NO_TEST=security update of a dependency
NO_DOC=security update of a dependency

Just regular update to bring ncurses security fixes into tarantool.

New version brings a number of functional and security fixes:
- ncurses 6.3 before patch 20220416 has an out-of-bounds read and
segmentation violation in convert_strings in tinfo/read_entry.c in the
terminfo library (CVE-2022-29458).
- ncurses through v6.2-1. _nc_captoinfo in captoinfo.c has a heap-based
buffer overflow (CVE-2021-39537).

CVE-2022-29458 Detail: https://nvd.nist.gov/vuln/detail/CVE-2022-29458
CVE-2021-39537 Detail: https://nvd.nist.gov/vuln/detail/CVE-2021-39537
Release announcement: https://lists.gnu.org/archive/html/bug-ncurses/2022-07/msg00008.html

NOTE: Build system uses a link to tarball on a local storage instead of
official mirror [1].

1. https://invisible-mirror.net/archives/ncurses/current/

NO_TEST=security update of a dependency
NO_DOC=security update of a dependency

Just regular update to bring openssl security fixes into tarantool.

Added a patch for Mac OS to fix a build failure, see
https://github.com/openssl/openssl/issues/18720.

Changelog: https://www.openssl.org/news/cl111.txt
Vulnerabilities: https://www.openssl.org/news/vulnerabilities.html

NO_TEST=security update of a dependency
NO_DOC=security update of a dependency

Just regular update to bring openssl security fixes into tarantool.

Fixes #6947

NO_TEST=security update of a dependency
NO_DOC=security update of a dependency

This patch updates libicu version to 71.1.
See changelog for details (https://icu.unicode.org/download/71).
The main reason to do that is a bug in datetime parsing that was
found using icu-date module (tarantool/icu-date#27)
and was fixed in linicu upstream
(https://unicode-org.atlassian.net/browse/ICU-21802).

NO_DOC=build
NO_TEST=build

Use a new storage bucket, made specifically for open-source
third-party software distributions.

NO_DOC=testing
NO_TEST=testing
NO_CHANGELOG=testing

zlib.net is unavailable, so we have to download zlib distributions
from a backup storage on VKCS S3.

NO_DOC=testing
NO_TEST=testing
NO_CHANGELOG=testing

Investigation of GNU libunwind problems on the aarch64-linux-gnu
platform drive us to the conclusion that libunwind-1.2.1 provided by
major distribution packages is broken. Not to mention that its test
suite fails with SEGFAULTs.

Last but not least, some distributions, e.g. CentOS 8 (see #4611) do
not provide a libunwind package.

Hence, bundle libunwind: bundling is enabled by default on all
platforms, except for macOS — a system package can be used if its
version is greater or equal than 1.3.0 (minimal version that does not
seem to be broken on aarch64-linux-gnu).

* Add new submodule: bump it to current master.
* Refactor libunwind package search logic out of compiler.cmake.
* Add CMake script for building bundled libunwind.
* Add CMake script for extracting version of libunwind.
* Re-enable backtrace for all RHEL distributions by default.
* Remove libunwind from static build.

Needed for #4002
Closes #4611

NO_DOC=build system
NO_TEST=build system

Fix static build for macOS 11.5 or higher.
On macOS SDK ver. 11.5 some `*.dylib` files was replaced with `*.tbd`.
So we replace `libunwind.dylib` on `libunwind.tbd`.
Because of macOS 10.15 support being dropped
conditional is not needed.

Closes #6052

If the tarantool repository is used as a submodule named <foobar> in
another repository, then the statically built binary will be placed in

  <binary_dir>/<foobar>/src/tarantool

not in

  <binary_dir>/src/tarantool

where static-build/CMakeLists.txt currently tries to look it up in order
to run `ctest` and so we can't use static-build/CMakeLists.txt as is.

Let's instead use

  <install_dir>/bin/tarantool

This way `ctest` will work for static-build in both open-source and EE
repository without requiring any modifications.

Previously, URI can be passed as a string, which contains one URI
or several URIs separated by commas. Now URIs can be passed in
different ways: as before, as a table which contains URI and it's
parameters in "param" table, as a table which contains URI strings
and URI tables. Also there are different ways to specify properties
for URI: in a string which contains URI, after '?' delimiter, in a
table which contains URI in "params" table, in "default_params" table
if it is default parameters for all URIs.
For this purposes new method `parse_many` was implemented in tarantool
`uri` library. Also `parse` method was updated to make possible the
same as new `parse_many` method but only for single URI.
```lua
uri = require('uri')
-- Single URI, passed as before
uri.parse_many("/tmp/unix.sock")
-- Single URI, with query paramters
uri.parse_many("/tmp/unix.sock?q1=v1&q2=v2")
-- Several URIs with parameters in one string, separated by commas
uri.parse_many("/tmp/unix.sock_1?q=v, /tmp/unix.sock_2?q=v")
-- Single URI passed in table, with additional parameters, passed
-- in "params" table. This parameters overwrite parameters from
-- URI string (q1 = "v2" in example below).
uri.parse_many({"/tmp/unix.sock?q1=v1", params = {q1 = "v2"}})
-- For parse it's also works now
uri.parse({"/tmp/unix.sock?q1=v1", params = {q1 = "v2"}})
-- Several URIs passed in table with default parameters, passed
-- in "default_params" table, which are used for parameters, which
-- not specified for URI (q3 parameter with "v3" value corresponds
-- to all URIs, and used if there is no such parameter in URI).
uri.parse_many({
    "/tmp/unix.sock_1?q1=v1",
    { uri = "/tmp/unix.sock_2", params = { q2 = "v2" } },
    default_params = { q3 = "v3" }
})
```

Implement ability to parse a string, which contains several URIs
separated by commas. Each URI can contain different query parameters
after '?'. All created URIs saved in new implemented struct `uri_set`.

Part of #5928

In the future, it is planned to extend the URI structure to allow its
passing with different options and in different formats (see next commit
`uri: implement ability to parse URI query paramters` for example). For
these purposes, it is planned to use functions that modify the source
string, for example `strtok_r`, so we need to rework the URI structure
to create copies of the string for each of the URI components.

Part of #5928

Without it `tarantoolctl rocks` would require luarocks to be installed
on the system, which isn't always possible.

It got broken in 54be00b6
("error: use error_payload in Lua"). 2 symbols were dropped from
the exports but not from this test.

Follow-up #5568

Exporting symbols of a third party library is not a best practice,
as we know from [1]. Let's wrap the msgpack symbols that need to
be exported with the "tnt_" prefix.

While working on the patch, it was decided to export the msgpack
symbols that are used in "msgpuckffi.lua".
In test shared libraries where the symbols "mp_***_{decimal,uuid}"
are used, they are replaced to exported "tnt_mp_***_{decimal,uuid}",
because in the case of linking with "libcore.a" the "libcore.a"
needs to be rebuild with the "-fPIC" flag, that seems as overkill
for tests.

1. https://github.com/tarantool/memcached/issues/59

Closes #5932

After unhiding all internal symbols([1]) we experience a bunch of
problems ([2], [3]). The second one (clash of symbols from different version
of the "small" library) still have no good solution.
You can find more on the topic [4].

The situation for tarantool executable is the same as for any other library.
A library should expose only its public API and should not increase probability
of hard to debug problems due to clash of a user's code with an internal name
from the library.

Let's hide all symbols by default and create a list of exported symbols.
(In fact, this patch is a revert of the patch
03790ac5 ([5]) taking into account the changes
made to the code)

Explanation of adding some controversial symbols to the export list:

* The following symbols are used in shared libraries used in tests
  ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so",
  "gh-5938-wrong-string-length.so", "module_api.so")

    mp_check
    mp_encode_array
    mp_encode_bin
    mp_encode_bool
    mp_encode_int
    mp_encode_map
    mp_encode_nil
    mp_encode_str
    mp_encode_uint
    mp_decode_array_slowpath
    mp_decode_str
    mp_next_slowpath
    mp_load_u8
    mp_next
    mp_sizeof_array
    mp_sizeof_str
    mp_type_hint
    decimal_from_string

* These symbols are used in "crypto.lua" and, if absent, will lead to the
  failure of the "static_build_cmake_linux" on CI (the crypto prefix was
  used to avoid the clashes of names)

    crypto_ERR_error_string
    crypto_ERR_get_error
    crypto_EVP_DigestInit_ex
    crypto_EVP_DigestUpdate
    crypto_EVP_DigestFinal_ex
    crypto_EVP_get_digestbyname
    crypto_HMAC_Init_ex
    crypto_HMAC_Update
    crypto_HMAC_Final

* For correct work of "schema.lua" in the "static_build_cmake_linux"

    rl_get_screen_size

* The following symbols are used in "ssl-cert-paths-discover.test.lua"
  (I think these symbols will have to be wrapped in the to avoid clashes
  problems)

    X509_get_default_cert_dir_env
    X509_get_default_cert_file_env
    ssl_cert_paths_discover

From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and
"tt_uuid_str" (see [7]).

1. https://github.com/tarantool/tarantool/issues/2971
2. https://github.com/tarantool/tarantool/issues/5001
3. https://github.com/tarantool/memcached/issues/59
4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html
5. https://github.com/tarantool/tarantool/commit/03790ac5510648d1d9648bb2281857a7992d0593
6. https://github.com/tarantool/tarantool/issues/4225
7. https://github.com/tarantool/tarantool/commit/acf8745ed8fef47e6d1f1c31708c7c9d6324d2f3

Part of #5932

commit fbc04dfb
("static-build: use hashes of downloaded files") added hashes for
ExternalProject_Add() to avoid extra downloads on project rebuild.
Changes for libicu and libiconv were missed and this patch fixes it.

Follows-up #5761

Co-authored-by: Sergey Bronnikov <sergeyb@tarantool.org>

There was a global ibuf object called tarantool_lua_ibuf. It was
used in all the places working with Lua which didn't have yields,
and where fiber's region could be potentially slower due to not
being able to guarantee the allocated memory is contiguous.

Yields during the ibuf usage were prohibited because another fiber
would take the same ibuf and override its previous content which
was still used by another fiber.

But it wasn't taken into account that there is Lua GC. It can be
invoked from any Lua function in Lua C code, and almost on any
line in the Lua scripts. During GC some deleted objects might have
GC handlers installed as __gc metamethods. From the handler they
could call Tarantool functions, including the ones using the
global ibuf.

Therefore ibuf could be overridden not only at yields, but almost
in any moment. Because with the Lua GC at hand, the multitasking
is not strictly "cooperative" anymore.

It is necessary to implement ownership for the global buffer. The
patch prepares the API for this: the buffer is moved to its own
file, and has methods take(), put(), and drop().

Take() is supposed to make the current fiber own the buffer. Put()
makes it available again. Drop() does the same but also clears the
buffer (frees its memory). The ownership itself is a subject for
the next patches. Here only the API is prepared.

The patch "hits" performance a little. Previously the get of
buffer.IBUF_SHARED cost around 1 ns. Now cord_ibuf_take() +
cord_ibuf_put() cost around 5 ns together. The next patches will
make it worse, up to 15 ns until #5871 is done.

Part of #5632

We use cmake instead of autotools to build curl. Change was introduced
in commit 11dcc9cb ("build: remove
autotools from packages spec"). No sense to require autoconf, automake
and libtool to build tarantool.

Part of #5652

Part of #5652

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

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

Refactored static build process to use static-build/CMakeLists.txt
instead of Dockerfile.staticbuild (this allows to support static
build on macOS). Following third-party dependencies for static build
are installed via cmake `ExternalProject_Add`:
  - OpenSSL
  - Zlib
  - Ncurses
  - Readline
  - Unwind
  - ICU

* Added support static build for macOS
* Fixed `CONFIGURE_COMMAND` while building bundled libcurl for static
  build at file cmake/BuildLibCURL.cmake:
    - disable building shared libcurl libraries (by setting
      `--disable-shared` option)
    - disable hiding libcurl symbols (by setting
      `--disable-symbol-hiding` option)
    - prevent linking libcurl with system libz (by setting
      `--with-zlib=${FOUND_ZLIB_ROOT_DIR}` option)
* Removed Dockerfile.staticbuild
* Added new gitlab.ci jobs to test new style static build:
  - static_build_cmake_linux
  - static_build_cmake_osx_15
* Removed static_docker_build gitlab.ci job

Closes #5095

Co-authored-by: Yaroslav Dynnikov <yaroslav.dynnikov@gmail.com>