Note that targets for running performance tests are generated only when
CMAKE_BUILD_TYPE is equal to Release or RelWithDebug. Additionally, C++
performance tests require Google Benchmark library. Using non-debug
build and having installed Google Benchmark library is rare case, so I
suppose we don't need to introduce CMake option for performance testing.

NO_CHANGELOG=testing
NO_DOC=testing
NO_TEST=testing infrastructure

(cherry picked from commit a63d291b)

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.

(cherry picked from commit ff57f990)

This commit adds two new Lua functions:
 - `box.malloc.info()` is a public function that returns the total
   memory usage of internal data structures allocated with `malloc()`.
   This information is extracted from the `malloc_info()` output.
   See the doc bot request for details.
 - `box.malloc.internal.info()` is an internal function that returns
   a parsed XML document returned by `malloc_info()` as is. It isn't
   documented. We may need it to get the detailed information about
   the system memory allocator.

Both functions are useful only on Linux and only if ASAN is disabled
because otherwise `malloc_info()` is unavailable. On other platforms
`box.malloc.info()` reports zero memory usage while `internal.info()`
returns an empty table.

Closes #7311

@TarantoolBot document
Title: Document `box.malloc.info()`

`box.malloc.info()` is a function that returns a table with two fields:

```
tarantool> box.malloc.info()
---
- size: 2498560
  used: 1835726
...
```

The `used` value is the total amount of memory in bytes allocated by
Tarantool for internal data structures with [`malloc()`][1].

The `size` value is the total amount of memory in bytes allocated from
the system by the `malloc()` allocator. It may not be less than `used`.

The function may be used before `box.cfg()` is called.

Currently, the function is available only on Linux. On other systems it
reports zero memory usage (`{size = 0, used = 0}`).

[1]: https://man7.org/linux/man-pages/man3/malloc.3.html

(cherry picked from commit d34a0cbc)

To improve customer experience it was decided to disable JIT engine on
Tarantool startup for macOS builds. Either way, JIT will be aboard as a
result of the changes and more adventurous users will be able to enable
it via <jit.on> in their code.

Furthermore, for convenient maintenance of JIT default behaviour CMake
configuration option "LUAJIT_JIT_STATUS" is introduced.

Closes #8252

NO_DOC=no behaviour changes

(cherry picked from commit ae0db476)

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

This feature was disabled due to a crash in libunwind. After commit
5b08d71a ("libunwind: use latest release v1.6.2 as a base") the
crash is gone.

Closes #7960

NO_DOC=internal
NO_CHANGELOG=internal
NO_TEST=<Leak backtraces are tested by test/unit/fiber.cc; the crash in
libunwind is observable on test/box-luatest/gh_6310_grant_rw_access_on_
_session_settings_space_to_public_role_test.lua>

Since we are going to introduce zlib compression in enterprise version,
we need to find zlib package there, so let's search for zlib package
only if it has not been found before.

NO_TEST=cmake
NO_CHANGELOG=no behavior changes
NO_DOC=no behavior changes

As it breaks sane usage of region as a data stack:

	size_t region_svp = region_used(&fiber()->gc);
	/* some allocation on fiber gc and usage of allocated memory. */
	region_truncate(&fiber()->gc, region_svp);

If in the above snippet one calls a function that in turn calls
`fiber_gc` then the snippet code may have use-after-free and later UB
on truncation.

For this reason let's get read of fiber_gc. However we need to make sure
we won't introduce leaks this way. So before actually removing
fiber_gc we make it perform leak check instead and only after fixing
all the leaks the fiber_gc was removed.

In order to find the leak easily the backtrace of the first fiber gc
allocation that is not truncated is saved and then reported.

In order to catch leaks that are not triggered by the current test suit
and to prevent introducing leaks in future patches the leak check is
added on fiber exit/recycle and for long living system fibers on every loop
iteration.

Leak check in release build is on but without leak backtrace info by
default for performance reasons. Backtrace can be provided by using
`fiber.leak_backtrace_enable()` knob before starting leaking fiber.

Regularly leaks are only reported in log but it will not help to
catch errors when running test suits so build option ABORT_ON_LEAK
is added. When it is on we abort on leak. This option is turned off
for all builds that used in CI.

Closes #5665

NO_CHANGELOG=internal
NO_DOC=internal

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

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

strerror() is MT-Unsafe, because it uses a static buffer under the hood.
We should use strerror_r() instead, which takes a user-provided buffer.
The problem is there are two implementations of strerror_r(): XSI and
GNU. The first one returns an error code and always writes the message
to the beginning of the buffer while the second one returns a pointer to
a location within the buffer where the message starts. Let's introduce a
macro HAVE_STRERROR_R_GNU set if the GNU version is available and define
tt_strerror() which writes the message to the static buffer, like
tt_cstr() or tt_sprintf().

Note, we have to export tt_strerror(), because it is used by Lua via
FFI. We also need to make it available in the module API header, because
the say_syserror() macro uses strerror() directly. In order to avoid
adding tt_strerror() to the module API, we introduce an internal helper
function _say_strerror(), which calls tt_strerror().

NO_DOC=bug fix
NO_TEST=code is covered by existing tests

CMake accepts the following case-insensitive values as true: 1, ON, YES,
TRUE, Y, or a non-zero number (including floating point numbers). This
complicates the parsing of ENABLE_BACKTRACE in `tarantool.build.options`.
Fix this by defining it to TRUE for any true value.

Part of #7535

NO_DOC=internal
NO_CHANGELOG=internal

It is convenient to fast check, whether the option was enabled or
disabled. Especially, when cmake is called indirectly, say, by a package
manager on Gentoo.

Follows up #3308

NO_DOC=quite minor build process change
NO_TEST=has no relation to tarantool behavior
NO_CHANGELOG=see NO_DOC

strlcat is a function from BSD, which is designed to be safer, more
consistent, and less error prone replacement for strcat and strncat.

NO_DOC=internal
NO_CHANGELOG=internal

Part of #7534

The option was forgotten back when bundled c-ares was just introduced.
Let's fix this now for the sake of consistency with other options.

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

LuaJIT submodule is bumped to introduce the following changes:
* sysprof: change C configuration API
* sysprof: enrich symtab on a new trace or a proto
* sysprof: fix SYSPROF_HANDLER_STACK_DEPTH
* sysprof: make internal API functions static
* sysprof: add LUAJIT_DISABLE_SYSPROF to Makefile
* symtab: check the _GNU_SOURCE definition

Within this changeset Tarantool-specific backtrace handler is introduced
and set to be used by sysprof machinery.

Besides, all new public Lua C API introduced within this changeset is
added to extra/exports.

Follows up #781

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump
NO_CHANGELOG=LuaJIT submodule bump

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.

This commit allows to override Tarantool version detection by setting
CMake TARANTOOL_VERSION variable. This is needed to build Tarantool as a
part of tarantool/sdk, which sets its own, extended version.

Also, this commit updates box-py/args.test.py to allow arbitrary tags
appended to the version (tarantool/sdk appends -rNNN).

Submodules are auto-updated in two cases:
1. When cmake is called for the first time (and there's no
   src/lib/small/CMakeLists.txt).
2. If git-describe version doesn't match the version stored in the
   VERSION file.

The first case looks okay, but the second one is confusing. It means
that the following sequence of commands does NOT update submodules:

```sh
cmake . # initial configuration, fetches small
cd src/lib/small && git checkout HEAD^ && cd - # checkout small
cmake . # does NOT update small
```

while the following sequence of commands does:

```sh
git commit --allow-empty -m dummy
cmake . # updates small!
```

This looks confusing, inconsistent, and dangerous. Let's drop this code
and let the developers update submodules manually when they need to.

This effectively reverts commit c83eea60
("CMake: automatically update submodules").

Use git from CMAKE_SOURCE_DIR instead of PROJECT_SOURCE_DIR so that if
Tarantool is built as a sub-project, we will use the version of the main
project.

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

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.

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.

Part of #5385

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

`VERSION` files in small subproject and in tarantool are treated as C++
standard library on a filesystem with case-insensitive names. So we have
to delete the root of tarantool project from `include_directories` in
tarantool CMake. Also we have to change `include_directories` in tarantool
CMake from the root of `small` project to `include` subfolder in `small`
project.
Closes #6076

Ship libcurl headers to system path "${PREFIX}/include/tarantool"
in the case of libcurl included as bundled library or static
build. 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

Closes #4559

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>

Export libcurl's symbols only when they are provided by tarantool
itself: when the library is linked statically into the tarantool's
executable. There is no much sense to export the symbols when we link
against the library dynamically.

Regarding motivation of the change. Since 2.6.0-36-g29ec62891 ('Ensure
all curl symbols are exported') the curl_multi_poll() function is
exported from the tarantool executable. It leads to a failure in
Homebrew's build, because there we link (dynamically) with a system
libcurl. On Mac OS 10.15 it is libcurl 7.64.1, while the function
appears since libcurl 7.66.0. So a linker reports the undefined symbol:
`curl_multi_poll`.

Now the symbols are not exported at dynamic linking with libcurl, so the
linker is happy.

This commit relaxes bounds for dynamic linking, but an attempt to link
with libcurl older than 7.66.0 statically still leads to a linking
failure. The box-tap/gh-5223-curl-exports.test.lua test still fails when
tarantool is linked (dynamically) against an old libcurl.

It looks as the good compromise. When libcurl functionality is provided
by tarantool itself, *all* functions listed in the test are present
(otherwise a linker will complain). But tarantool does not enforce a
newer libcurl version, when it just *uses* this functionality and don't
provide it for modules and stored procedured. It is not tarantool's
responsibility in the case.

We possibly should skip the box-tap/gh-5223-curl-exports.test.lua test
when tarantool is built against libcurl dynamically or revisit the
described approach. I'll leave it as possible follow up activity.

Fixes #5542

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

Very convenient to have this string extension.
We will use it in crash handling.

Acked-by: Serge Petrenko <sergepetrenko@tarantool.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>