Without CA certificates the HTTP client will unable to verify server's
certificate, so the only way to perform an HTTPS request would be use
the `verify_peer = false` option -- disable certificate validation at
all.

The runtime search of system CA bundle/certificates was unintentionally
disabled in 2.10.0 (PR #7119). The patch enabled is back.

The main motivation behind the runtime search is difference in paths on
different systems. Since we ship Tarantool Enterprise Edition as
executable with ability to run on different Linux distributions, we
can't choose one particular path at build time. See details in #5746.

The `CURL_CA_BUNDLE_SET` and `CURL_CA_PATH_SET` options were removed,
because they are not 'real' curl configuration options, but rather
cached values to don't repeat file/directory search at re-configuration.
It looks as internal logic of Curl's CMake script.

NO_DOC=Lack of proper HTTPS support is definitely broken behavior, there
       is no sense to document it or the opposite.
NO_TEST=A simple test would require to send a request to external host.
        It would not work without internet connection or in a sandbox.
        Such test also would be unstable and would fail from time to
        time due to network conditions. I verified the patch manually. I
        have an idea to add more thorough http client testing later.

Fixes #7372

Changelog: https://curl.se/changes.html#7_84_0

New release contains fixes for 4 security problems [1].

Patch adds a new option defined in curl build infrastructure with it's
default value used in 7.84.0. NOTE: PSL is a Public Suffix List (PSL),
it is a list of suffixes used for cookies.

1. https://curl.se/docs/releases.html

NO_DOC=libcurl submodule bump
NO_TEST=libcurl submodule bump

__gcov_flush was removed in gcc11.

Since gcc11 __gcov_dump calls __gcov_lock at the start and
__gcov_unlock before returning. Same is true for __gcov_reset.
Because of that using __gcov_reset right after __gcov_dump since gcc11
is the same as using __gcov_flush before gcc11.

Closes #7302

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal

For the sake of maximizing backtrace collection performance, build
the libunwind project submodule with "-O2" compiler flag.

Also, build it with the "-g" compiler flag just in case to simplify
debugging.

Last but not least, pass the same archive-maintaining program used by the
main CMake project to the libunwind project submodule to make the build
homogeneous.

Needed for #7207

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

By default CMake generates Makefiles for building a project. However, it
allows to generate Ninja files. Ninja [1] may build project a bit faster
than Make, see [2].

Patch adds fixes for CMake files allowing to use Ninja for building
Tarantool:

1. Fixed dependencies in ExternalProject_Add(), see explanation in [3]
2. Fixed ninja error due to presence of symbol '$' in cmake/rpm.cmake
3. Added propagation of CMAKE_GENERATOR in dependencies that uses CMake
   for building, see [4]

How-to build wit Ninja:

$ cmake -G Ninja -B build -S .
$ ninja -C build/

1. https://ninja-build.org/
2. https://mesonbuild.com/Simple-comparison.html
3. https://stackoverflow.com/a/65803911/3665613
4. https://cmake.org/cmake/help/latest/module/ExternalProject.html

NO_DOC=internal
NO_CHANGELOG=internal
NO_TEST=internal

This reverts commit 33830978.

Follow-up #6477

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

Changelog: https://curl.se/changes.html#7_83_0

Curl replaced prefix CURL_ with CMAKE_ in private identifiers [1] since
the 'CMAKE_' prefix is reserved for CMake's own private use, see [2].

Patch adds a number of options defined in curl build infrastructure with
their default values used in 7.83.0.

1. https://github.com/curl/curl/commit/9108da2c26d18e927b91e33d3729d9cf0f3eb8fa
2. https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html

NO_DOC=libcurl submodule bump
NO_TEST=libcurl submodule bump

Follows up #6029

After fixing libunwind issues in 7dc9fe44, libcoro fibers issues in
761053f0 and c8ad49f0, we can now re-enable backtrace feature on
AARCH64.

For some not investigated reason `unw_backtrace` does not collect any
ips when "-mbranch-protection" compile feature is enabled: provide a
workaround for this case.

Closes #6060

NO_DOC=build system
NO_TEST=build system

* Default parse
  - new c-dt version used which handles extended years range
    while parse relaxed iso8601 gformat strings;
  - family of functions like dt_from_ymd_checked functions
    added to the new c-dt version, now used by conversion code
    to properly handle validation of a 32-bit boundary values;
  - datetime_parse_full() modified to properly handle huge years values;
  - added tests for extended years range.

* strptime-like parse
  - properly handle longer than 4 years values, negative values,
    and handle zulu suffix, which may be generated by Tarantool
    stringization routines;

Part of #6731

NO_DOC=internal
NO_CHANGELOG=internal

If Tarantool is built as a subproject, and there's a Lua source file
stored in the superproject directory, its path won't start with
PROJECT_SOURCE_DIR and hence won't be replaced with PROJECT_BINARY_DIR
by the lua_source() function. As a result, the lua.c file generated by
lua_source() will be put in the source directory instead of the binary
directory. Fix this by using CMAKE dirs instead of PROJECT dirs.

Ironically, CMAKE dirs were replaced with PROJECT dirs everywhere in
the first place to allow building Tarantool as a subproject, see commit
d8097325 ("cmake: align folders dependencies"). This patch basically
reverts that change.

NO_DOC=cmake
NO_TEST=cmake
NO_CHANGELOG=cmake

Fiber call-chains end at `coro_{init, startup}`, but unwinders don't
stop there, trying to use `coro_{init, startup}` stack frame's return
address (which points to some garbage) and, in turn, failing. A similar
issue was experienced by seastar and julia (see JuliaLang/julia#23074
and scylladb/scylla#1909).

In order to make unwinding stop at `coro_{init, startup}`'s stack frame
we need to annotate it with CFI assembly: previously, annotation was
provided only for GCC on x86_64 — also provide it if ENABLE_BACKTRACE is
set during configuration.

Zero out rbp on x86_64 (to conform to x86_64 ABI): this requires setting
"-fomit-frame-pointer" compile flag for coro.c.

Backtrace collection from inactive fiber based on pseudo context-switch
relied on the stack frame structure: remove redundant
"-fno-omit-frame-pointer" and "-fno-stack-protector"
compile flags for other Tarantool sources.

For some reason unwinders ignore platform ABIs regarding ending of
call-chains: explicitly invalidate the topmost (`coro_{init, startup}`)
current frame information (CFI) for both x86_64 and AARCH64.

References:
1. glibc:
 * clone: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/clone.S;h=31ac12da0cc08a934d514fed1de9eba1cb3e8ec5;hb=ebbb8c9f64c3486603ef4ccee4dd2a5574e41039
 * start: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/start.S;h=9edd17b60cd54ec9eef11c76ab02322dcb5d057a;hb=5b736bc9b55115e67129e77db4de6cf193054cd2
2. seastar:
 * thread_context::main(): https://github.com/scylladb/seastar/blob/d27bf8b5a14e5b9e9c9df18fd1306489b651aa42/src/core/thread.cc#L278-L293
3. julia:
 * https://github.com/JuliaLang/julia/blob/2e2b1d2ad50fe12999cbded0b5acd3f0a36ec8c5/src/julia_internal.h#L90-L106
4. android:
 * https://cs.android.com/android/platform/superproject/+/master:bionic/libc/platform/bionic/macros.h;l=52-60;drc=2528dab7419a63f57fe20027886ba7dd3857aba8

Needed for #4002

NO_DOC=internal bug fix
NO_CHANGELOG=internal bug fix
NO_TEST=unwind information annotation in inline assembly

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

Before this patch Tarantool http client did not support HTTP/2.
The reasons to enable HTTP/2 support are efficiency offered by
the protocol and potential ability to interact with a GRPC server.
The CMake version requirement is updated from 3.2 to 3.3, because
we need generator expressions in cmake for setting multiple paths
in CMAKE_FIND_ROOT_PATH for nghttp2 support.

Closes #5771

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

In tarantool/doc#2065 we requested to update
the CMake minimum version to 3.2. Now it is time for 3.3.
See details in the linked commit.

Needed for Tarantool EE. Off by default.

Currently, the symbol name is deducted from the filename, but it may
lead to name clashes if different packages have modules with same names.
Let's pass the symbol name explicitly to avoid that.

This is needed to embed luarocks in static build.

Zlib is used in OpenSSL and in libCURL. Besides, we will need it for
lua-zlib. So better define FindZLIB.

Note, `add_library(ZLIB::ZLIB UNKNOWN IMPORTED)` and setting the
corresponding properties in FindZLIB.cmake is needed to build libcurl,
which depends on zlib.

Use of PROJECT_ prefix gives ability to build the project as a
submodule of other projects.

 | [100%] Linking C static library libcurl-d.a
 | <...>
 | make[3]: *** No rule to make target `build/curl/dest/lib/libcurl.a',
 |     needed by `test/unit/luaL_iterator.test'. Stop.

The problem appears on Mac OS. It is a bit strange that we don't see it
on Linux. However I didn't dig into this, just fixed the observed
problem.

Related: https://github.com/curl/curl/issues/2121

Fixes #6656

Introduce a new builtin Tarantool module `datetime.lua` for timestamp
and interval types support.

New third_party module - c-dt
-----------------------------

* Integrated chansen/c-dt parser as 3rd party module to the
  Tarantool cmake build process;
* We use tarantool/c-dt instead of original chansen/c-dt to
  have an easier cmake build integration, as we have added some
  changes, which provide cmake support, and allow to rename symbols
  if necessary (this symbol renaming is similar to that we see
  with xxhash or icu).

New built-in module `datetime`
------------------------------

* created a new Tarantool built-in module `datetime`, which uses
  `struct datetime` data structure for keeping timestamp values;
* Lua module uses a number of `dt_*` functions from `c-dt` library,
  but they were renamed to `tnt_dt_*` at the moment of exporting
  from executable - to avoid possible name clashes with external
  libraries.

* At the moment we libc `strftime` for formatting of datetime
  values according to flags passed, i.e. `date:format('%FT%T%z')`
  will return something like '1970-01-01T00:00:00+0000', but
  `date:format('%A %d, %B %Y')` will return 'Thursday 01, January 1970'

* if there is no format provided then we use default
  `tnt_datetime_to_string()` function, which converts datetime
  to their default ISO-8601 output format, i.e.
  `tostring(date)` will return string like "1970-01-01T00:00:00Z"

* There are a number of simplified interfaces
  - totable() for exporting table with attributes names as provided
    by `os.date('*t')`
  - set() method provides unified interface to set values using
    the set of attributes as defined above in totable()

Example,

```
local dt = datetime.new {
	nsec      = 123456789,

	sec       = 19,
	min       = 29,
	hour      = 18,

	day       = 20,
	month     = 8,
	year      = 2021,

	tzoffset  = 180
}

local t = dt:totable()
--[[
{
	sec = 19,
	min = 29,
	wday = 6,
	day = 20,
	nsec = 123456789,
	isdst = false,
	yday = 232,
	tzoffset = 180,
	month = 8,
	year = 2021,
	hour = 18
}
--]]

dt:format()   -- 2021-08-21T14:53:34.032Z
dt:format('%Y-%m-%dT%H:%M:%S')   -- 2021-08-21T14:53:34

dt:set {
	usec      = 123456,

	sec       = 19,
	min       = 29,
	hour      = 18,

	day       = 20,
	month     = 8,
	year      = 2021,

	tzoffset  = 180,

}
dt:set {
	timestamp = 1629476485.124,

	tzoffset  = 180,
}

```

Coverage is

File                 Hits Missed Coverage
-----------------------------------------
builtin/datetime.lua 299  23     92.86%
-----------------------------------------
Total                299  23     92.86%

Part of #5941

@TarantoolBot document
Title: Introduced a new `datetime` module for timestamp and interval support

Create `datetime` module for timestamp and interval types support.
It allows to create date and timestamp values using either object interface,
or via parsing of string values conforming to iso-8601 standard.
One may manipulate (modify, subtract or add) timestamp and interval values.

Please refer to https://hackmd.io/@Mons/S1Vfc_axK#Datetime-in-Tarantool
for a more detailed description of module API.

OSX workflows use brew for install openssl.
There was a new release of openssl@3.0 and
homebrew updated the openssl formula.

Close #6468

To be able to configure libcurl for ARM64 CPU
on Fedora distros with linker hardening it is
necessary to enable `-fPIC`. It fails with wrong
relocation type for glibc symbols (e.g. socket)
otherwise.

Closes #6366

MacOS has its own libunwind which works not good with fibers
under M1. Backtraces need to be enabled again after #6060 is fixed.
Other arm backtraces are temporarily disabled too for #6222.

Closes #6272

Seems CMakeLists.txt contains the same line as inside
BuildZSTD.cmake. Seems we don't need to duplicate this logic
twice let's remove it.

This patch is the first step for fixing regression introduced in
f998ea39 (digest: introduce FFI bindings for xxHash32/64).
We used xxhash library that is shipped with zstd. However it's
possible that user doesn't use bundled zstd. In such cases we
couldn't export xxhash symbols and build failed with following
error:

```
[ 59%] Linking CXX executable tarantool
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xd80): undefined reference to `XXH32'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xd88): undefined reference to `XXH32_copyState'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xd90): undefined reference to `XXH32_digest'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xd98): undefined reference to `XXH32_reset'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xda0): undefined reference to `XXH32_update'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xda8): undefined reference to `XXH64'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xdb0): undefined reference to `XXH64_copyState'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xdb8): undefined reference to `XXH64_digest'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xdc0): undefined reference to `XXH64_reset'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/tarantool.dir/exports.c.o:(.data.rel+0xdc8): undefined reference to `XXH64_update'
collect2: error: ld returned 1 exit status
```

To avoid a problem this patch introduces standalone xxhash library
that will be bundled anyway. It's worth to mention that our
approach is still related to zstd. We use Cyan4973/xxHash that is
used in zstd and passes the same compile flags to it. Single
difference is usage of XXH_NAMESPACE to avoid symbols clashing
with zstd.

Need for #6135

This patch fixes inaccuracy in Tarantool build configuration introduced
by commit 07c83aab ('build: adjust
LuaJIT build system'). That patch sets LUAJIT_USE_ASSERT and
LUAJIT_USE_APICHECK options for Debug build instead of LUA_USE_ASSERT
and LUA_USE_APICHECK respectively. This patch fixes these typos.

Follows up #4862

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

This patch fixes inaccuracy in Tarantool build configuration introduced
by commit 07c83aab ('build: adjust
LuaJIT build system'). All those MacOS-related tweaks for __PAGEZERO
size and preferred load address for the bundle are necessary only for
builds with 32-bit GC area on 64-bit host. The only case fitting these
conditions is x86_64 with no LUAJIT_ENABLE_GC64. All other 64-bit builds
use 64-bit GC area unconditionally.

Part of #5983
Needed for #5629
Follows up #4862

Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Reviewed-by: Nikita Pettik <korablev@tarantool.org>
Reviewed-by: Sergey Ostanevich <sergos@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

Enable smtp and smtps protocols in bundled libcurl. 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

Part of #4559

`cmake` command was hardcoded for configuring libcurl, however only
`cmake3` may be installed in a system. Now we use the same cmake command
for configuring libcurl as one that is used for configuring tarantool
itself.

The problem exists since 2.6.0-196-g2b0760192 ('build: enable cmake in
curl build').

Fixes #5955

LuaJIT submodule is bumped to introduce the following changes:
* test: disable LuaJIT CLI tests in lua-Harness suite
* test: set USERNAME env var for lua-Harness suite
* test: adjust lua-Harness tests that use dofile
* test: adjust lua-Harness suite to CMake machinery
* test: add lua-Harness test suite

Within this changeset lua-Harness suite[1] is added to Tarantool
testing. Considering Tarantool specific changes in runtime the suite
itself is adjusted in LuaJIT submodule.

However, Tarantool provides and unconditionally loads TAP module
conflicting with the one used in the new suite. Hence, the Tarantool
built-in module is "unloaded" in test/luajit-test-init.lua.

Furthermore, Tarantool provides UTF-8 support via another built-in
module. Its interfaces differ from the ones implemented in Lua5.3 and
moonjit. At the same time our LuaJIT fork provides no UTF-8 support, so
lua-Harness UTF-8 detector is simply confused with non-nil utf8 global
variable. As a result, utf8 is set to nil in test/luajit-test-init.lua.

There are also some tests launching Lua interpreter, so strict need to
be disabled for their child tests too. Hence `strict.off()` is added to
`progname` (i.e. arg[-1] considering the way Tarantool parses its CLI
arguments) command used in these tests.

[1]: https://framagit.org/fperrad/lua-Harness/tree/a74be27/test_lua



Closes #5844
Part of #4473

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

LuaJIT submodule is bumped to introduce the following changes:
* test: adjust LuaJIT test suite for Tarantool
* test: change LuaJIT test suite to match b4e6bf0
* test: change LuaJIT test suite to match 5a61e1a
* test: change LuaJIT test suite to match c198167
* test: change LuaJIT test suite to match de5568e
* test: add LuaJIT-test-cleanup test suite
* test: fix Lua command in utils.selfrun
* test: fix luacheck invocation for non-real paths

Within this changeset LuaJIT-test-cleanup suite[1] is added to Tarantool
testing. Considering Tarantool specific changes in runtime the suite
itself is adjusted in LuaJIT submodule. However, there is <strict>
module enabled by default in Debug build, so the testing environment
need to be tweaked via test/luajit-test-init.lua script to be run prior
to every LuaJIT suite test is started.

[1]: https://github.com/LuaJIT/LuaJIT-test-cleanup/tree/014708b/test



Closes #4064
Part of #4473

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

Now `make luacheck` gracefully handles different cases[^1]: in-source
and out-of-source build (within the source tree or outside), current
working directory as a real path or with symlink components.

As result of looking into those problems I filed the issue [1] against
luacheck. It seems, there are problems around absolute paths with
symlinks components.

[^1]: We have the similar problems with LuaJIT's luacheck rule. They
      will be fixed in a separate patch.

[1]: https://github.com/mpeterv/luacheck/issues/208



Reviewed-by: Sergey Bronnikov <sergeyb@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

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>

If Lua source path given to <lua_source> function is relative, the
output file is generated in the binary directory. At the same time if
the given path to be compiled to *.lua.c is absolute, the output
file is generated in source directory instead of the binary one. This
patch fixes the latter case, providing the valid behaviour for out of
source build type.

Needed for #4862

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

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

To run Tarantool fuzzers on OSS Fuzz infrastructure it is needed to pass
library $LIB_FUZZING_ENGINE to linker and use external CFLAGS and
CXXFLAGS. Full description how to integrate with OSS Fuzz is in [1] and
[2].

Patch to OSS Fuzz repository [2] is ready to merge.

We need to pass options with "-fsanitize=fuzzer" two times
(in cmake/profile.cmake and test/fuzz/CMakeLists.txt) because:

- cmake/profile.cmake is for project source files,
  -fsanitize=fuzzer-no-link option allows to instrument project source
  files for fuzzing, but LibFuzzer will not replace main() in these
  files.

- test/fuzz/CMakeLists.txt uses -fsanitize=fuzzer and not
  -fsanitize=fuzzer-no-link because we want to add automatically
  generated main() for each fuzzer.

1. https://google.github.io/oss-fuzz/getting-started/new-project-guide/
2. https://google.github.io/oss-fuzz/advanced-topics/ideal-integration/
3. https://github.com/google/oss-fuzz/pull/4723

Closes #1809

There is a number of bugs related to parsing and encoding/decoding data.
Examples:

- csv: #2692, #4497, #2692
- uri: #585

One of the effective method to find such issues is a fuzzing testing.
Patch introduces a CMake flag to enable building fuzzers (ENABLE_FUZZER)
and add fuzzers based on LibFuzzer [1] to csv, http_parser and uri
modules. Note that fuzzers must return 0 exit code only, other exit
codes are not supported [2].

NOTE: LibFuzzer requires Clang compiler.

1. https://llvm.org/docs/LibFuzzer.html
2. http://llvm.org/docs/LibFuzzer.html#id22

How-To Use:

$ mkdir build && cd build
$ cmake -DENABLE_FUZZER=ON \
	-DENABLE_ASAN=ON \
	-DCMAKE_BUILD_TYPE=Debug \
	-DCMAKE_C_COMPILER="/usr/bin/clang" \
	-DCMAKE_CXX_COMPILER="/usr/bin/clang++" ..
$ make -j
$ ./test/fuzz/csv_fuzzer -workers=4 ../test/static/corpus/csv

Part of #1809

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

Initially tried to change autoconf tools in Curl build to cmake and
found the following build issue on:

  CentOS 6
  CentOS 7
  Debian 8
  Ubuntu 14.04

Issue found:

  CMake Error at CMakeLists.txt:41 (cmake_minimum_required):
    CMake 3.0 or higher is required.  You are running version 2.8.12.2

To fix the issue check is removed of the version from curl sources
in Tarantool's third party '<root Tarantool sources>/third_party/curl':

  12af024bc85606b14ffc415413a7e86e6bbee7eb ('Enable curl build with old cmake')

After this fix completely changed autoconf to cmake in curl build.
Autoconf part was completely removed and code cleaned up for cmake.
For curl cmake build all autoconf options were ported to cmake
configuration call, check the accurate list of the change in [1].

Also the following issues resolved:

1. Found that CURL cmake configuration file:

     third_party/curl/lib/CMakeLists.txt

   has installation part for built libcurl.a library:

     install(TARGETS ${LIB_NAME}
       EXPORT ${TARGETS_EXPORT_NAME}
       ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
       LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}

   where it changes CMAKE_INSTALL_LIBDIR to appropriate name with
   suffix of the architecture, like:

     lib
     lib64
     x86_64

   Found that find_library routine from the file:

     cmake/FindLibCURL.cmake

   returns only 'lib' value and it breaks the building of the depends
   binaries. To avoid of it the CMAKE_INSTALL_LIBDIR option was set to
   cmake call:

     -DCMAKE_INSTALL_LIBDIR=lib

2. Found issue with building on CentOS 6:

     Linking C executable curl
     build/ares/dest/lib/libcares.a(ares__timeval.c.o): In function `ares__tvnow':
     ares__timeval.c:(.text+0x15): undefined reference to `clock_gettime'
     collect2: error: ld returned 1 exit status

   It was fixed with added "-lrt" flag to CMAKE_C_FLAGS and
   CMAKE_CXX_FLAGS build flags, when cmake version is lower
   than 3.0 and RT library had needed function.

3. Found issues with building Tarantool statically on Debian 9 and
   its package build on CentOS 8.

   Building statically got the issues with openssl linking, like [2]:

     static-build/openssl-prefix/lib/libcrypto.a(threads_pthread.o): In function `CRYPTO_THREAD_lock_new':
     threads_pthread.c:(.text+0x45): undefined reference to `pthread_rwlock_init'

   It happened because in openssl radically changed how threads-related
   things were handled before 1.1.0 version. It required the application
   to provide us with the locking functionality in form of callbacks.
   Since 1.1.0, these matters are entirely internal, so libcrypto
   requires the presence of the platform specific thread implementation
   of our choosing, which is pthread on everything.

   After '-pthread' added to C compile flags package build on CentOS 8
   failed with the issue [3]:

     /build/usr/src/debug/tarantool-2.6.0.141/third_party/curl/lib/warnless.c:101:4: error: #error "SIZEOF_CURL_OFF_T not defined"
      #  error "SIZEOF_CURL_OFF_T not defined"
         ^~~~~
     /build/usr/src/debug/tarantool-2.6.0.141/third_party/curl/lib/warnless.c: In function 'curlx_uztoso':
     /build/usr/src/debug/tarantool-2.6.0.141/third_party/curl/lib/warnless.c:192:40: error: 'CURL_MASK_SCOFFT' undeclared (first use in this function); did you mean 'CURL_MASK_SINT'?
      return (curl_off_t)(uznum & (size_t) CURL_MASK_SCOFFT);
                                           ^~~~~~~~~~~~~~~~
                                           CURL_MASK_SINT

   To avoid of the issue decided to use '-pthread' flag only for openssl
   when it had not this flag in openssl compilation.

4. Found issue with static build using CentOS 7, where SSL cmake rule
   failed. Building the image got the issue:

      [  1%] Performing configure step for 'bundled-libcurl-project'
      CMake Warning at CMakeLists.txt:50 (message):
        the curl cmake build system is poorly maintained.  Be aware

      -- curl version=[7.66.0-DEV]
      -- Found c-ares: /tarantool/build/ares/dest/lib/libcares.a
      Found *nroff option: -- -man
      CMake Error at /usr/share/cmake/Modules/FindOpenSSL.cmake:278 (list):
        list GET given empty list
      Call Stack (most recent call first):
        CMakeLists.txt:347 (find_package)

   Root cause of the issue that Dockerfile uses globaly
   installed openSSL with:

     cmake ... -DOPENSSL_ROOT_DIR=/usr/local ...

   Its cmake build file:

     /usr/share/cmake/Modules/FindOpenSSL.cmake

   fails on parsing the SSL version:

   it has:
          REGEX "^#define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")

   but it should to use:
          REGEX "^#[\t ]*define[\t ]+OPENSSL_VERSION_NUMBER[\t ]+0x([0-9a-fA-F])+.*")

   Anyway we want to use the same OpenSSL library for libcurl, as is used
   for Tarantool itself. So the path to it set for cURL build:

     list(APPEND LIBCURL_CMAKE_FLAGS "-DCMAKE_MODULE_PATH=${PROJECT_SOURCE_DIR}/cmake")

5. In CMake build CMAKE_USE_LIBSSH2 flag is enabled by default, while
   in autoconf --with-libssh2 was disabled by default. We need to switch
   CMAKE_USE_LIBSSH2 flag off with:

     list(APPEND LIBCURL_CMAKE_FLAGS "-DCMAKE_USE_LIBSSH2=OFF")

   to avoid of linking issues, like:

     ld: libssh2.c:(.text+0x4d8): undefined reference to `libssh2_*...

   this issue exists in curl issues [4].

   Furthermore the following defaults are also disabled to keep the
   configuration consistent with autoconf one:

     list(APPEND LIBCURL_CMAKE_FLAGS "-DPICKY_COMPILER=OFF")
     list(APPEND LIBCURL_CMAKE_FLAGS "-DBUILD_CURL_EXE=OFF")

Closes #4968
Closes #5019
Closes #5396

[1] - https://github.com/tarantool/tarantool/issues/4968#issue-617183031
[2] - https://gitlab.com/tarantool/tarantool/-/jobs/779176133#L6021
[3] - https://gitlab.com/tarantool/tarantool/-/jobs/778309145#L3060
[4] - https://github.com/curl/curl/issues/1146

Prior to these changes bootstrap.h was generated right in the source
directory even for out of source build. Firstly such approach doesn't
respect the idea of building outside the source files. Furthermore
this leads to build failures when the source directory is located on
read-only file system.

As a result of the patch bootstrap.h is generated within the build
tree and include directories are adjusted the corresponding way.

Also changed destination build directory from source to binary path.

Part of #4968

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>