The patch introduces a new CMake target "checkpatch", that checks
patches on top of the master branch using script checkpatch.pl [1]. By
default CMake looking for `checkpatch.pl` in a directory "checkpatch" in
Tarantool's repository root directory and in a directories specified in
PATH. By default commit revisions range checked by checkpatch is
`origin/master..HEAD`, `origin/master` could be overridden with
environment variable `CHECKPATCH_GIT_REF`.

1. https://github.com/tarantool/checkpatch

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

We run SVACE on static build. It doesn't compile unless libsvace is in
the allow list.

Follow-up #9242

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

SVACE stopped working after commit 98b38e89 ("cmake: allow to
bundle static dependencies in main project") changed the bundled libs
directory layout. To fix this, let's introduce the new cmake option
BUNDLED_LIBS_INSTALL_DIR and set it in static-build/CMakeLists.txt to
the legacy location. Also, let's use the legacy directories for each
external project's PREFIX, SOURCE_DIR, BINARY_DIR, and STAMP_DIR.

Follow-up #9242

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

Instead of using ctest, let's simply run the CheckDependencies.cmake as
a post build command if Tarantool was built without dependencies. The
good thing about it is that the check will run even if the static build
is created directly, without the /static-build/CMakeLists.txt wrapper.

Part of #9242

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

zzip is installed to lib64/ on some systems by default so we need to
explicitly set the install dir to lib/.

Fixes commit 140fd681 ("cmake: allow to use bundled zzip").

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

There's EMBED_LUZIP cmake option that embeds the Lua zip module in
Tarantool binary. Since the Lua zip module depends on the zzip library,
it also links the zzip library. The option is used only by Tarantool EE
so there's no config for bundling the zzip library in the CE repository.
Now, that we bundle all static build dependencies in the main project
cmake config, let's add zzip bundling code here as well. The code of
/cmake/BuildZZIP.make is copied from /static-build/CMakeLists.txt of
the EE repository.

Follow-up #9242

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

The BUILD_STATIC cmake config option forces the build system link
Tarantool binary statically with its dependencies. It expects that all
static libraries on which Tarantool binary depends are available at
build time.

We don't use this option directly to create static binaries because it
would produce different results on different build systems. Instead, we
use the separate cmake config located in the static-build directory,
which fetches all Tarantool dependencies from a predefined location
before building a static binary.

Having a separate cmake config is inconvenient. Let's enable bundling of
static binary dependencies right in the main project cmake config, like
we bundle, for example, libcurl. To achieve that, the new build option
was introduced BUILD_STATIC_WITH_BUNDLED_LIBS. It implies BUILD_STATIC
and also fetches and builds all required dependencies, like the
static-build cmake config used to. The latter doesn't do it anymore;
from now on, it just sets BUILD_STATIC_WITH_BUNDLED_LIBS when building
Tarantool. We can't remove the static-build cmake config yet because
there are quire a few CI workflows depending on it.

Note that, just like BUILD_STATIC, BUILD_STATIC_WITH_BUNDLED_LIBS
doesn't imply OPENSSL_USE_STATIC_LIBS so the latter should be set
explicitly if one wants to use the static openssl library. However,
setting OPENSSL_USE_STATIC_LIBS with BUILD_STATIC_WITH_BUNDLED_LIBS will
force the build system use bundled static openssl library.

This patch is relatively straightforward. It just moves the external
projects from /static-build/cmake/AddDependencyProjects.cmake to /cmake
adding build dependencies where required and setting variables that are
set by the corresponding /cmake/FindXXX.cmake configs.

There are a few things that should be noted separately though:
 - We dropped the ZLIB_FOUND check from the main project cmake config.
   It was used for building EE but the latter is going to be broken
   anyway once this patch is committed. We'll fix it in following
   commits.
 - FindLibUnwind referenced zlib library by ZLIB::ZLIB. We don't set
   it for bundled zlib so let's use ZLIB_LIBRARIES instead.
 - We don't need to detect dependency cflags while building bundled
   libraries as we can reuse the flags set by the main project.
 - We don't use HARDENING_LDFLAGS because it makes no sense when
   building static libraries.

Closes #9242

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

Currently, we simply include the libyaml source directory into the main
project. The problem is that libyaml uses ICU. If ICU is built outside
the main project cmake config, as it's the case with the static-build,
both the main project and libyaml cmake configs will use the same ICU
version. However, if we build ICU in the main project, as we intend to
do to resolve #9242, it may not work. To fix that, we need to use the
external project API to build libyaml.

Needed for #9242

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

The patch updates curl module to the version 8.3.0 [1] and updates a
CMake module for building curl library.

Changes in CMake module:

- Option `CURL_STATICLIB` is gone and replaced with `BUILD_STATIC_LIBS`.
- Option `CURL_USE_GNUTLS` was added and disabled by default.
- NSS library support was removed and option `CURL_USE_NSS` has been
  removed as well.
- Option `CMAKE_UNITY_BUILD` was added and disabled by default.
- Option `CURL_DISABLE_FORM_API` was added and disabled by default. It is
  in fact depends on `CURL_DISABLE_MIME`, but anyway disabled explicitly.

Changelog: https://curl.se/changes.html#8_3_0

1. https://github.com/curl/curl/releases/tag/curl-8_3_0

NO_DOC=libcurl submodule bump
NO_TEST=libcurl submodule bump

Fixes #9086

This patch fixes the following warning:

NO_WRAP
  CMake Warning (dev) at cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
    The package name passed to `find_package_handle_standard_args`
    (GetLIBUNWINDVersion.cmake) does not match the name of the calling package
    (LibUnwind).  This can lead to problems in calling code that expects
    `find_package` result variables (e.g., `_FOUND`) to follow a certain
    pattern.
  Call Stack (most recent call first):
    cmake/FindLibUnwind.cmake:82 (find_package_handle_standard_args)
    CMakeLists.txt:552 (find_package)
NO_WRAP

Closes #6998

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

All LuaJIT related LSan warnings were suppressed in the scope of the
commit 985548e4 ("asan: suppress all
LSAN warnings related to LuaJIT"), since all compiler flags tweaks were
enclosed in LuaJIT CMake machinery. As a result of the commit in LuaJIT
submodule tarantool/luajit@a86e376 ("build: introduce LUAJIT_USE_ASAN
option") ASan and LSan support has been finally added to LuaJIT runtime,
so it was decided to remove LSan suppressions for LuaJIT functions.
Unfortunately, it was not so easy as it looked like.

At first, Lua global state is not closed properly at Tarantool instance
exit (see <tarantool_free> in src/main.cc and <tarantool_lua_free> in
src/lua/init.c for more info), so LSan false-positive leaks are detected
(for more info, see #3071). Hence, the original LSan suppression for
lj_BC_FUNCC is returned back (temporarily) until the aforementioned
issue is not resolved.

Furthermore, the internal LuaJIT memory allocator is not instrumented
yet, so to find any memory faults it's worth building LuaJIT with system
provided memory allocator (i.e. enable LUAJIT_USE_SYSMALLOC option).
However, again, since Tarantool doesn't finalize Lua universe the right
way, so running Tarantool testing routine with LUAJIT_USE_SYSMALLOC
enabled generates false-positive LSan leaks. Return back here to enable
LUAJIT_USE_SYSMALLOC, when #3071 is resolved.

Last but not least, the default value of fiber stack size is 512Kb, but
several tests in test/PUC-Rio-Lua-5.1-test suite in LuaJIT submodule
(e.g. some cases with deep recursion in errors.lua or pm.lua) have
already been tweaked according to the limitations mentioned in #5782,
but the crashes still occur while running LuaJIT tests with ASan support
enabled. Experiments once again confirm the notorious quote that "640 Kb
ought to be enough for anybody".

Anyway, LuaJIT tests are added to <test-release-asan> target in .test.mk
and LUAJIT_TEST_ENV is extended with required ASan and LSan options.

Follows up #5878

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

In scope of the commit 82f4b4a3 ("lib/core/fiber: Increase default
stack size") the default value of fiber stack size is increased up to
512 Kb (you can find the reasons in the aforementioned commit message
and in https://github.com/tarantool/tarantool/issues/3418 description).

Some of the tests in test/PUC-Rio-Lua-5.1-test suite in LuaJIT repo
(e.g. some cases with deep recursion in errors.lua or pm.lua) have
already been tweaked according to the limitations mentioned in
https://github.com/tarantool/tarantool/issues/5782, but the crashes
still occurs while running LuaJIT tests with ASan support enabled.

To make the testing routine more convenient, FIBER_STACK_SIZE option is
introduced to Tarantool CMake machinery. One can provide the size either
by raw digits (i.e. in bytes) or using Kb/Mb suffixes for convenience.

A couple of important nits:
* If the given value is not a multiple of 4Kb, CMake machinery adjusts
  it up to the nearest one greater than this value.
* If the adjusted value is less than 512Kb, configuration fails with the
  corresponding CMake fatal error.

Follows up #3418
Relates to #5782

@TarantoolBot document
Title: introduce FIBER_STACK_SIZE configuration option

To make managing of the default fiber stack size more convenient, the
corresponding CMake option is added.

**NB**: The stack size can't be less than 512Kb and if the given value
is not a multiple of 4Kb, CMake machinery adjusts it up to the nearest
one greater than this value.

There are sporadic segfaults in libunwind during backtrace_collect().
Reproducible with the latest version, and there are open issues with
similar stacks:

https://github.com/libunwind/libunwind/issues/150
https://github.com/libunwind/libunwind/issues/260
https://github.com/libunwind/libunwind/issues/473

Let's disable ENABLE_BACKTRACE for AArch64 Linux until these issues are
resolved in libunwind.

Closes #8572
Part of #8791

NO_DOC=bugfix

It was disabled because ligomp.a on some AArch64 systems (e.g. CentOS)
is compiled without PIC support. Now Tarantool doesn't depend on ligomp,
so it's safe to turn on PIC for AArch64 systems.

Follow-up #7536

NO_DOC=build
NO_TEST=build

It was disabled because dlsym tests failed when PIC is on (#7640).
However, later it turned out that the issue is not related to PIC, and
LuaJIT was turned off for such tests by commit 67e79b15 ("test: turn
LuaJIT off in tests with dlsym"). Now it's safe to turn on PIC for FreeBSD.

Follow-up #7536

NO_DOC=build
NO_TEST=build

OpenMP is no longer used since commit 4f617b70 ("box: introduce
memtx_sort_threads config parameter"). All dependencies on libgomp
should be removed.

Follow-up #7689

NO_DOC=build
NO_TEST=build

`string` with JOIN option is only available since CMake 3.12, but we have
developers using CMake 3.1: implement a utility `string_join` function to
remove this dependency.

Closes #5881

NO_CHANGELOG=<build fix>
NO_DOC=<build fix>
NO_TEST=<build fix>

Closes #3389
Closes #7689
Closes #4646

@TarantoolBot document
Title: new box.cfg parameter memtx_sort_threads

The parameter sets the number of threads used to sort keys of secondary
indexes on loading memtx database. The parameter cannot be changed
dynamically (as it does not make sense).

Maximum value is 256, minimum is 1. Default is to use all available cores.

Usage example:
```
box.cfg{memtx_sort_threads=4}
```

Patch made following changes:
- add a CMake function lua_multi_source that unpacks symbol names and
  Lua source paths in passed list and compiles Lua source into *.lua.c
  sources using lua_source() function. Function is needed for embedding
  Lua modules consisting from a number of files to Tarantool EE.
- add using lua_multi_source instead of lua_source for etcd client module.
- remove function prototypes and declarations related to extra features.
  All this code is moved to Tarantool EE source code.

Part of #8620
Follows up https://github.com/tarantool/tarantool-ee/issues/443

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

Patch introduce a macro FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION. It is
a common build macro recommended in libFuzzer's documentation [1].

1. https://llvm.org/docs/LibFuzzer.html#fuzzer-friendly-build-mode

Needed for #4826

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

Follows-up #4823

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal

Added Google's 'libprotobuf-mutator' and 'protobuf' libraries
for developing grammar-based LuaJIT and SQL fuzzers based on
LibFuzzer.

It is needed to build protobuf module from source because
by default, the system-installed version of protobuf is used
by libprotobuf-mutator, and this version can be too old.

Part of #4823

NO_CHANGELOG=<dependencies>
NO_DOC=<dependencies>
NO_TEST=<dependencies>

Updating libcurl from 7.84.0 to 7.87.0 in commit 09f4eca1
("third_party: update libcurl from 7.84.0 to 7.87.0")
made it impossible to built tarantool with bundled curl with nghttp2,
because nghttp2 was not updated to fit libcurl 7.87.0, this led to
missing function
nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation
during linking step.

https://github.com/nghttp2/nghttp2/releases/tag/v1.52.0

Closes #8268

NO_DOC=there is no known behavior changes, consider the change as not
       visible for a user
NO_TEST=can only reproduce in specific environment
NO_CHANGELOG=see NO_DOC

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

New release contains fixes for 7 security problems [1]:

https://curl.se/docs/CVE-2022-35252.html
https://curl.se/docs/CVE-2022-32221.html
https://curl.se/docs/CVE-2022-35260.html
https://curl.se/docs/CVE-2022-42915.html
https://curl.se/docs/CVE-2022-42916.html
https://curl.se/docs/CVE-2022-43551.html
https://curl.se/docs/CVE-2022-43552.html

Patch adds a new option ENABLE_WEBSOCKETS defined in curl build
infrastructure with it's default value used in 7.87.0.

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

NO_DOC=libcurl submodule bump
NO_TEST=libcurl submodule bump

Closes #8150

The EE CMakeConfig.txt adds CE as a sub-directory. For this to work,
we should use project dir instead of cmake dir in CE cmake files,
see commit d8097325 ("cmake: align folders dependencies").

Fixes commit 14f93aee ("libunwind: improve incremental
build/rebuild").

Follow-up #8019

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

Currently we use ExternalProject_Add to build libunwind subproject. The
usecases it supports are not quite aligned with our. Configuration and
build steps are rerun in case download step sees updated sources. But
we use git submodules to fetch third-party projects and thus subproject
is not rebuild when it's files are changed on disk. Either because of
we doing some sort of experiments locally or because the new sources
are brought by git pull.

Actually libunwind has a CMakeList.txt so that we could try to build it
just as project subdirectory. But it requires quite a fresh CMake
version, currently supports only build on Visual Studio and probably is
not up to date given it's package version variables. Keeping
CMakeLists.txt in sync with main autotools build is additional
maintenance burden. So I'd like to use main autotools build.

So ext_project_autotools function is added to provide nicer build
integration with third-party projects which are build using autotools.
Actually incremental rebuild works only if CMake is at least 3.12 but
I think this should be true for developer installations.

Hopefully we can reuse the function in case we need to bundle more
subprojects with autotools builds.

Follow-up #5665

NO_DOC=build improvement
NO_TEST=build improvement
NO_CHANGELOG=build improvement

Fixed pthread-related CMake checks. The checks code is built with
`-pedantic-errors` and it leads to errors of the following kind on
clang 15:

```
<...>/CMakeFiles/CMakeScratch/TryCompile-78KaOK/src.c:4:17: error: a
    function declaration without a prototype is deprecated in all
    versions of C [-Werror,-Wstrict-prototypes]
        int main() { pthread_setname_np(pthread_self(), ""); }
                ^
                 void
```

Fixed a warning in the SQL code (it's an error in Debug build):

```
<...>/src/box/sql/vdbeaux.c:170:13: error: variable 'n' set but not used
    [-Werror,-Wunused-but-set-variable]
        static int n = 0;
```

Fixed several warnings from lemon.c of the following kind:

```
<...>/extra/lemon.c:173:6: warning: a function declaration without a
    prototype is deprecated in all versions of C and is treated as a
    zero-parameter prototype in C2x, conflicting with a subsequent
    definition [-Wdeprecated-non-prototype]
void FindRulePrecedences();
     ^
<...>/extra/lemon.c:766:6: note: conflicting prototype is here
void FindRulePrecedences(struct lemon *xp)
```

See also https://github.com/tarantool/small/issues/57

Fixes #8110

NO_DOC=build fix
NO_TEST=build fix

Not used anywhere anymore. No need in it, because SHA1 is provided by
the OpenSSL library.

Closes #7987

NO_DOC=code cleanup
NO_TEST=code cleanup
NO_CHANGELOG=code cleanup

This option enables emission of the DWARF CFI (Call Frame Information)
directives to the assembler. It is enabled by default on most compilers,
but on GCC 7 for AArch64 and older it wasn't [1], so turn it on explicitly.
When enabled, the compiler emits .cfi_* directives that are required for
the stack unwinding, and defines __GCC_HAVE_DWARF2_CFI_ASM.

Part of #7960

[1] https://gcc.gnu.org/pipermail/gcc-patches/2018-March/495549.html

NO_DOC=internal
NO_CHANGELOG=internal
NO_TEST=Tested by test/app-luatest/fiber_parent_backtrace_test.lua

In the scope of this commit check for instruction/line hooks for
compiled code is turned on. As a result a special pad is emitted to the
trace validating whether any debug hook is fired while this trace is
being executed.

Closes #7762

NO_DOC=internal

Reviewed-by: Sergey Kaplun <skaplun@tarantool.org>
Reviewed-by: Maxim Kokryashkin <m.kokryashkin@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

Now we base on some unreleased state of libunwind. This is by itself not
a good practice. Yet the main motivation is that in the current version of
libunwind fast path for backtrace detection on x86_64 does not work.
I guess this is because of libunwind/libunwind@400b3f819ad4 (" x86_64: Stop
aliasing RSP and CFA"). See libunwind/libunwind#440. Fortunately this
commit is not present it the latest release.

Using fast or slow path has a great impact on performance of debug build
where collecting fiber gc allocation backtrace is turned on by default.
It surely depends on frequency and pattern of allocation. Test
sql/delete3 depends on backtrace performance most dramatically. On some
installations collecting backtraces slowed down the test up to 10 times.

If fast path is available then collecting backtrace does not affect
performance in a noticeable way.

I propose not to keep autotools products in the libunwind fork repo as
it is done previously. LOG_CONFIGURE is removed because it somehow
incompatible with using && in CONFIGURE_COMMAND command and not critical
to the build.

Also add autotools build dependencies for packpack package specs.
Currently not all packpack images have autotools preinstalled so this is
required for build to success. Anyway we'b better have precise build
requirements in build specs.

Follow-up #5665

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

This patch removes an old CMake kludge, which sets CMAKE_SYSTEM_PROCESSOR
to "x86_64" on all 64-bit architectures, even on ARM (on Darwin).

Closes #7495

NO_DOC=bugfix

After revisiting the list of currently disabled compiler warnings it seems
like the following are unjustifiably disabled:
* `-Wunknown-pragmas`;
* `-Wstrict-aliasing`;
* `-Wunused-value`;
* `-Wchar-subscripts`;
* `-Wformat-truncation`.

`-Wunused-value` appeared to be disabled due to a bug in Clang (see also
llvm/llvm-project#14119): according to the LLVM release dates, the last
affected Clang version was 3.1 and it was hopefully fixed in Clang 3.2.
No currently alive (or recently EOLed) distributions offer such old Clang
versions.

Strict aliasing violation warnings coming from libev cannot be disabled
with `system_header` pragma on GNU compilers older than 8, so we have to
leave to leave it disabled for the whole project in this case.

Otherwise, enable the warnings listed above for the sake of code health.

Closes #7862

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

The `-Wa,--debug-prefix-map` compiler flag breaks GNU-based LTO, and also
we cannot reliably test this feature.

Follow-up 256da010

NO_CHANGELOG=bugfix
NO_DOC=bugfix
NO_TEST=bugfix

Since our diagnostics use the `__FILE__` macro, they provide absolute
paths, which is kind of redundant and inconsistent: replace them with
relative ones.

As for debugging information, replacing absolute paths with relative ones
also requires an extra command to tell the debugger where to find the
source files, which is not convenient for developers: provide a new
`DEV_BUILD` option (turned off by default), which replaces absolute paths
with relative ones in debugging information if turned off.

Strip the prefix map flags from compiler flags exported to tarantool via
`src/trvia/config.h`.

Closes #7808

NO_DOC=<verbosity>
NO_TEST=<verbosity>

Setting hardening compiler flags is used in three places: default build,
static build and enterprise build — refactor it into a separate module.

Follow-up e6abe1c9

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

e6abe1c9 passes compiler flags to dependencies via a `<project>_build` macro
parameter, which is, firstly, inconvenient, and, secondly, as a result, not
all dependencies got the required compiler flags passed: use global
variables instead and pass these flags to skipped dependencies.

Follow-up e6abe1c9

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

`add_compile_flags` macro relied on undefined behaviour: instead of
unsetting the `_lang` and `_flag` variables, it tried to unset their
values — fix this.

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

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