With libunwind/libunwind@f67ef28 we can now use `unw_backtrace` with
PAC enabled on AARCH64 and remove the workaround with glibc's `backtrace`
for this case.

Closes #7285

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

Introduce cmake option ENABLE_HARDENING, which is TRUE by default for
non-debug regular and static builds, excluding AArch64 and FreeBSD.
It passess compiler flags that harden Tarantool (including the bundled
libraries) against memory corruption attacks. The following flags are
passed:

* -Wformat - Check calls to printf and scanf, etc., to make sure that
  the arguments supplied have types appropriate to the format string
  specified.

* -Wformat-security -Werror=format-security - Warn about uses of format
  functions that represent possible security problems. And make the
  warning into an error.

* -fstack-protector-strong - Emit extra code to check for buffer
  overflows, such as stack smashing attacks.

* -fPIC -pie - Generate position-independent code (PIC). It allows to
  take advantage of the Address Space Layout Randomization (ASLR).

* -z relro -z now - Resolve all dynamically linked functions at the
  beginning of the execution, and then make the GOT read-only.

Also do not disable hardening for Debian and RPM-based Linux distros.

Closes #5372
Closes #7536

NO_DOC=build
NO_TEST=build

The GENERATED and HEADER_FILE_ONLY source file properties should be
followed by a boolean value. CMake 3.20+ warns if it is not so, see [1].

It seems, the module.h properties do not actually change anything
visible in our case.

[1]: https://cmake.org/cmake/help/latest/policy/CMP0118.html

NO_DOC=pure code health patch, no visible changes
NO_TEST=pure code health patch, no visible changes
NO_CHANGELOG=pure code health patch, no visible changes

c-ares relies on libresolv on OS X, and when built statically, brings
the same dependency on to libcurl.

Link libcurl with libresolv explicitly when linking with c-ares

NO_DOC=build fix
NO_TEST=build fix
NO_CHANGELOG=build fix

Updated third_party/zstd submodule from v1.5.0 to 1.5.2 version.
The new version fixes a few bugs found by fuzzing testing.

Note, the new zstd version contains a .S source file so we need to
include ASM to the CMake project languages.

NO_DOC=build
NO_TEST=build

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