luarocks version updated to version 3.9.2

Closes #6597

NO_DOC=The engine has been updated, the functionality has not changed
NO_TEST=see NO_DOC

(cherry picked from commit 1dc8cd81)

tarantool/metrics [1] is a lua module (distributed as a separate rock)
for metrics aggregation and export. After this patch, it will be a part
of the tarantool binary.

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

Part of #7725

@TarantoolBot document
Title: embedded metrics

Now tarantool has metrics module on its board. metrics is a lua module
previously distributed as a separate rock which is widely used by
tarantool applications. Metrics has its own documentation section:
https://www.tarantool.io/en/doc/latest/book/monitoring/ , but it doesn't
yet mention anything about the embedding.

(cherry picked from commit 82ebbb35)

tarantool/checks [1] is a lua module (distributed as a separate rock)
for function input validation. After this patch, it will a part of
the tarantool binary.

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

Closes #7726
Needed for #7725

@TarantoolBot document
Title: embedded checks

Now tarantool has checks module on its board. checks is a lua module
previously distributed as a separate rock which is widely used by
many other tarantool lua modules (like cartridge, metrics and crud) and
tarantool applications. checks has its own repo with README covering its
API usage: https://github.com/tarantool/checks/blob/master/README.md .

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

libunwind/libunwind@f67ef28 adds the ability for libunwind to unwind a
stack where the return address obtained from the AARCH6 link register (x30)
has a pointer authentication code (PAC).

Needed for #7285

NO_CHANGELOG=<internal submodule version bump>
NO_DOC=<submodule version bump>
NO_TEST=<submodule version bump>

The current version of Luarocks used in tarantool has a
security vulnerability:
https://github.com/luarocks/luarocks/pull/1019

This issue is fixed in release 3.1.3, commit:
6ffa8cbe2bcdea2c1ee0f4b32291d179210707b6

Part of https://github.com/tarantool/security/issues/12

NO_DOC=bugfix
NO_TEST=bugfix
NO_CHANGELOG=bugfix

FreeBSD Tarantool port has some problems if build uses cmake'
ExternalProject_Add which refers to the github repository.
Sumodule works better - so switching to using it.

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

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.

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.

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.

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

Since the commit ae7e2103 we use internal serializer
thus we no longer need serpent code.

The patch removes the references from the source code
and .gitmodules file, still one might need to run

 | git submodule deinit -f third_party/serpent

manually to clean up the working tree depending
on local git version.

Closes #5517

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>

libcurl has a built-in threaded resolver used for asynchronous DNS
requests, however, when DNS server is slow to respond, the request still
hangs tarantool until it is finished. The reason is that curl calls
thread_join on the resolving thread internally upon timeout, making the
calling thread hang until resolution has ended.
Use c-ares as an asynchronous resolver instead to eliminate the problem.

Closes #4591

A manual action is needed after pulling of this commit to actually use
the downstream repository instead of the upstream one:

sed -i -e 's@https://github.com/curl/curl.git@https://github.com/tarantool/curl.git@' .git/config

It is part of our processes to use forked repositories for submodules.

Suggested by Konstantin Osipov.

Hold libcurl-7.65.3. This version is not affected by the following
issues:

* #4180 ('httpc: redirects are broken with libcurl-7.30 and older');
* #4389 ('libcurl memory leak');
* #4397 ('HTTPS seem to be unstable').

After this patch libcurl will be statically linked when
ENABLE_BUNDLED_LIBCURL option is set. This option is set by default.

Closes #4318

@TarantoolBot document
Title: Tarantool dependency list was changed

* Added build dependencies: autoconf, automake, libtool, zlib-devel
  (zlib1g-dev on Debian).
* Added runtime dependencies: zlib (zlib1g on Debian).
* Removed build dependencies: libcurl-devel (libcurl4-openssl-dev on
  Debian).
* Removed runtime dependencies: curl.

The reason is that now we use compiled-in libcurl: so we don't depend on
a system libcurl, but inherit its dependencies.

We will use it for Lua console output format serialization

Part-of #3834

Made tarantoolctl compatible with luarocks-3.x.

Fixes #4052.

Add fixed-point decimal type to tarantool core.
Adapt decNumber floating-point decimal library for the purpose, write a
small wrapper and add unit tests.

A new decimal type is an alias for decNumber numbers from the decNumber
library.
Arithmetic operations (+, -, *, /) and some mathematic functions
(ln, log10, exp, pow, sqrt) are available together with methods to
pack and unpack decimal to and from its packed representation (useful
for serialization).

We introduce a single context for all the arithmetic operations
on decimals, which enforces both number precision and scale to be
in range [0, 38]. NaNs and Infinities are restricted.

Part of #692

Usage:

    tarantoolctl rocks install ROCK - install a rock
    tarantoolctl rocks remove ROCK - remove a rock
    tarantoolctl rocks show ROCK - show information about an installed rock
    tarantoolctl rocks search PATTERN - search repository for rocks
    tarantoolctl rocks list - list all installed rocks

There are no other commands, options, configuration files. Our official
repository (http://rocks.tarantool.org) works out of the box. All rocks
are installed to ${PWD}/.rocks directory to support separate rocks trees
per project, as proposed by #2067. Rockspec can use "tarantool >= 1.7.x"
inside dependencies = {} block to depend on a specific Tarantool version.

LuaRocks has been slightly hacked to support custom configuration
via site_config.lua. There are no other changes in the upstream code.
It is not a fork and it isn't going to be a fork. All formats, layouts
and rockspecs are 100% compatible with the upstream LuaRocks 2017-07-10.

This feature intentionally doesn't have CMake option to disable it,
because it should be provided on all available platforms out of the box.

Other changes:

 * Add ${PWD}/.rocks to default package.path/package.cpath
 * Hack tarantoolctl to display subcommands in --help.
   Currently command line arguments handling are not perfect, but
   it can be fixed only by a new argparse implementation.

Closes #2067

Sophia was an experimental storage engine in 1.6.x.
Please use 'vinyl' engine in Tarantool 1.7 instead.

Closes #2040

Needed for #1689

* Use our own fork
* Fix typo in CMakeLists.txt
* Update build dependecies in README.md
* Fix a potential bug with buffer size calculation in ss_lz4filter_next()

Bump memory limit to 2GB

Requested by @kostja

move tarantool/sophia to tarantool-1.6 branch