We have a method for getting the number of elements stored in a BPS
tree. Let's use it instead of accessing BPS tree internals directly
so that we can freely refactor BPS tree internals.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

 - Add bps_tree_delete_value to the comment and declarations.
   (All other public methods are there.)
 - Fix typo in a comment: approxiamte -> approximate.
 - Fix comment to bps_tree_random.
 - Remove repeated word 'count' from comments.

NO_DOC=no change
NO_TEST=no change
NO_CHANGELOG=no change

 - Rename bps_tree_iterator_are_equal to bps_tree_iterator_is_equal for
   consistency with other methods that check two objects for equality
   (for example, tt_uuid_is_equal).

 - Rename bps_tree_iterator_first and bps_tree_iterator_last to
   bps_tree_first and bps_tree_last, because these are methods of
   bps_tree, not bps_tree_iterator. Omitting _iterator is also
   consistent with bps_tree_lower_bound and bps_tree_upper_bound
   methods, which also create bps_tree_iterator objects.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

In case of reverse iterators, due to index limitations, we need to clarify
the successor tuple early: this implies that the successor's story is not
always at the top of the history chain, whilst we need to add the gap item
to the story currently present in index — fix this by reusing the
iterators' check logic to set the current iterator's tuple (which is
considered the successor) to a tuple in index.

CLoses #7409

NO_DOC=bugfix

All the 'base' TREE index iterator `next` methods (including
`tree_iterator_start`) internally set the iterator's current tuple to the
one found in the index satisfying the conditions: setting the iterator's
current tuple to the clarified one is redundant and moreover gives a
performance penalty each iteration because of the iterator check logic.

Needed for #7409

NO_CHANGELOG=refactoring
NO_DOC=refactoring
NO_TEST=refactoring

The `next` method of memtx HASH index 'GT' iterator is initially set to
'GT' and is supposed to be set to 'GE' after first iteration: it is
mistakenly set to the 'base' method instead of the full method which also
does tuple clarification — this allows dirty reads. Move the `next` method
change on first iteration to `WRAP_ITERATOR_METHOD` for clarity and
correctness.

Closes #7477

NO_DOC=bugfix

Currently, there's no notion of a LIGHT hash table read view per se -
one can create an iterator over a regular hash table and then "freeze"
it. This works just fine for snapshotting and joining replicas, but this
spartan API doesn't let us implement user read views, because to do that
we need to do lookups and create iterators over a frozen hash table as
many times as we want, not just once.

So this patch introduces a concept of LIGHT(view), which contains a
frozen image of a LIGHT(core) and implements a subset of non-modifying
LIGHT(core) methods:

 - LIGHT(view_count)
 - LIGHT(view_find)
 - LIGHT(view_find_key)
 - LIGHT(view_get)
 - LIGHT(view_iterator_begin)
 - LIGHT(view_iterator_key)
 - LIGHT(view_iterator_get_and_next)

Note, LIGHT(core) and LIGHT(view) share LIGHT(iterator), because
iterator methods (begin, key, get_and_next) take LIGHT(core) or
LIGHT(view). The LIGHT(iterator) now contains only a hash table slot.

We could also implement the rest of non-modifying methods, but didn't do
that, because they are not needed to implement user read views:

 - LIGHT(random)
 - LIGHT(selfcheck)

To create a LIGHT(view) from a LIGHT(core), one is supposed to call
LIGHT(view_create). If a LIGHT(view) is no longer needed, it should be
destroyed with LIGHT(view_destroy).

Old methods used for creating frozen iterators were dropped:

 - LIGHT(iterator_freeze)
 - LIGHT(iterator_destroy)

To avoid code duplication, we factored out the common part of
LIGHT(core) and LIGHT(view) into a new structure, named LIGHT(common).
Basically, the new structure contains all LIGHT(core) members except
matras, which is stored in LIGHT(core). The difference between
LIGHT(view) and LIGHT(core) is that the latter stores matras_view
instead of matras. The common part contains pointers to matras and
matras_view, which are used by internal implementation to look up
LIGHT(record).

All internal methods now take LIGHT(common) instead of LIGHT(core).
For all public methods that are implemented both for LIGHT(core) and
LIGHT(view), we have the common implementation defined in _impl suffixed
private function, which is called by the corresponding public functions.

To ensure that a modifying method isn't called on LIGHT(common) object
corresponding to a LIGHT(view) because of a bug in the LIGHT code, we
added !matras_is_read_view_created assertion to LIGHT(touch_record),
LIGHT(prepare_first_insert), and LIGHT(grow).

Closes #7192

NO_DOC=refactoring
NO_CHANGELOG=refactoring

Currently, matras_get and matras_touch are called directly. Since soon
we'll need to pass a matras_view to those methods, let's add convenience
wrappers.

Needed for #7192

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This commit moves the code that gets the index of a random light
record from the memtx hash index implementation to a new light method.
This gives us more freedom of refactoring the light internals without
modifying the code using it.

After this change, LIGHT(pos_valid) isn't needed anymore so it's
inlined in LIGHT(random).

Needed for #7192

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This commit adds a function that retrieves the number of records stored
in a light hash table and makes light users use it instead of accessing
the light count directly. This gives us more freedom of refactoring the
light internals without modifying the code using it.

Needed for #7192

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

Update luacheckrc to suppress all warnings from lua vars with `_` prefix.
This allows to declare a function with an expected standardized interface
without unused var warning.
Fix luacheck warnings in src/box/console.lua.

Closes #5032

NO_CHANGELOG=warning fix
NO_DOC=warning fix
NO_TEST=warning fix

prbuf_check, which is called by prbuf_open, proceeds to scanning the
buffer even if it's empty. On debug build, this results in prbuf_open
reporting that the buffer is corrupted, because we trash the buffer in
prbuf_create. On a release build, this may lead to a hang, in case the
buffer is zeroed out. Let's fix this by returning success from
prbuf_check if the buffer is empty. Note, prbuf_iterator_next doesn't
call prbuf_first_record if the buffer is empty, either.

Needed for https://github.com/tarantool/tarantool-ee/issues/187

NO_DOC=bug fix
NO_CHANGELOG=will be added to EE

This list contains several header files, which has no
`/** cond public */` and `/** \endcond public */` instructions.

While I'm on it, drop `/** \endcond public */` from box.cc.

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

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

The main decision made in this patch is how large the public
`box_decimal_t` type should be. Let's look on some calculations.

We're interested in the following values.

* How much decimal digits is stored?
* Size of an internal decimal type (`sizeof(decimal_t)`).
* Size of a buffer to store a string representation of any valid
  `decimat_t` value.
* Largest signed integer type fully represented in decimal_t (number of
  bits).
* Largest unsigned integer type fully represented in decimal_t (number
  of bits).

Now `decimal_t` is defined to store 38 decimal digits. It means the
following values:

| digits | sizeof | string | int???_t | uint???_t |
| ------ | ------ | ------ | -------- | --------- |
| 38     | 36     | 52     | 126      | 127       |

In fact, decNumber (the library we currently use under the hood) allows
to vary the 'decimal digits per unit' parameter, which is 3 by default,
so we can choose density of the representation. For example, for given
38 digits the sizeof is 36 by default, but it may vary from 28 to 47
bytes:

| digits | sizeof     | string | int???_t | uint???_t |
| ------ | ---------- | ------ | -------- | --------- |
| 38     | 36 (28-47) | 52     | 126      | 127       |

If we'll want to store `int128_t` and `uint128_t` ranges, we'll need 39
digits:

| digits | sizeof     | string | int???_t | uint???_t |
| ------ | ---------- | ------ | -------- | --------- |
| 39     | 36 (29-48) | 53     | 130      | 129       |

If we'll want to store `int256_t` and `uint256_t` ranges:

| digits | sizeof     | string | int???_t | uint???_t |
| ------ | ---------- | ------ | -------- | --------- |
| 78     | 62 (48-87) | 92     | 260      | 259       |

If we'll want to store `int512_t` and `uint512_t` ranges:

| digits | sizeof       | string | int???_t | uint???_t |
| ------ | ------------ | ------ | -------- | --------- |
| 155    | 114 (84-164) | 169    | 515      | 514       |

The decision here is what we consdider as possible and what as unlikely.
The patch freeze the maximum amount of bytes in `decimal_t` as 64. So
we'll able to store 256 bit integers and will NOT able to store 512 bit
integers in a future (without the ABI breakage at least).

The script, which helps to calculate those tables, is at end of the
commit message.

Next, how else `box_decimal_*()` library is different from the internal
`decimal_*()`?

* Added a structure that may hold any decimal value from any current or
  future tarantool version.
* Added `box_decimal_copy()`.
* Left `strtodec()` out of scope -- we can add it later.
* Left `decimal_str()` out of scope -- it looks dangerous without at
  least a good explanation when data in the static buffer are
  invalidated. There is `box_decimal_to_string()` that writes to an
  explicitly provided buffer.
* Added `box_decimal_mp_*()` for encoding to/decoding from msgpack.
  Unlike `mp_decimal.h` functions, here we always have `box_decimal_t`
  as the first parameter.
* Left `decimal_pack()` out of scope, because a user unlikely wants to
  serialize a decimal value piece-by-piece.
* Exposed `decimal_unpack()` as `box_decimal_mp_decode_data()` to keep a
  consistent terminogoly around msgpack encoding/decoding.
* More detailed API description, grouping by functionality.

The script, which helps to calculate sizes around `decimal_t`:

```lua
-- See notes in decNumber.h.

-- DECOPUN: DECimal Digits Per UNit
local function unit_size(DECOPUN)
    assert(DECOPUN > 0 and DECOPUN < 10)
    if DECOPUN <= 2 then
        return 1
    elseif DECOPUN <= 4 then
        return 2
    end
    return 4
end

function sizeof_decimal_t(digits, DECOPUN)
    -- int32_t digits;
    -- int32_t exponent;
    -- uint8_t bits;
    -- <..padding..>
    -- <..units..>
    local us = unit_size(DECOPUN)
    local padding = us - 1
    local unit_count = math.ceil(digits / DECOPUN)
    return 4 + 4 + 1 + padding + us * unit_count
end

function string_buffer(digits)
    -- -9.{9...}E+999999999# (# is '\0')
    -- ^ ^      ^^^^^^^^^^^^
    return digits + 14
end

function binary_signed(digits)
    local x = 1
    while math.log10(2 ^ (x - 1)) < digits do
        x = x + 1
    end
    return x - 1
end

function binary_unsigned(digits)
    local x = 1
    while math.log10(2 ^ x) < digits do
        x = x + 1
    end
    return x - 1
end

function digits_for_binary_signed(x)
    return math.ceil(math.log10(2 ^ (x - 1)))
end

function digits_for_binary_unsigned(x)
    return math.ceil(math.log10(2 ^ x))
end

function summary(digits)
    print('digits', digits)
    local sizeof_min = math.huge
    local sizeof_max = 0
    local DECOPUN_sizeof_min
    local DECOPUN_sizeof_max
    for DECOPUN = 1, 9 do
        local sizeof = sizeof_decimal_t(digits, DECOPUN)
        print('sizeof', sizeof, 'DECOPUN', DECOPUN)
        if sizeof < sizeof_min then
            sizeof_min = sizeof
            DECOPUN_sizeof_min = DECOPUN
        end
        if sizeof > sizeof_max then
            sizeof_max = sizeof
            DECOPUN_sizeof_max = DECOPUN
        end
    end
    print('sizeof min', sizeof_min, 'DECOPUN', DECOPUN_sizeof_min)
    print('sizeof max', sizeof_max, 'DECOPUN', DECOPUN_sizeof_max)
    print('string', string_buffer(digits))
    print('int???_t', binary_signed(digits))
    print('uint???_t', binary_unsigned(digits))
end
```

Part of #7228

@TarantoolBot document
Title: Module API for decimals

See the declarations in `src/box/decimal.h` in tarantool sources.

This is preparatory commit for exposing decimals into the module API.
We'll mark the argument in the public function as const, so it would be
more accurate to have it marked as const in the internal API as well.

Part of #7228

NO_DOC=this is internal API, no user-visible changes
NO_TEST=no behavior changes
NO_CHANGELOG=no user-visible changes

It is preparatory commit to add box/decimal.h header, which will hold
module API for decimals.

Part of #7228

NO_DOC=no user-visible changes
NO_TEST=no behavior changes
NO_CHANGELOG=no user-visible changes

This patch fixes the following issue: the submodule_update.yml workflow
always updated the tarantool submodule in the tarantool-ee repo to the
last commit from the `master` branch, even if it was tarantool-ee 2.10.
Now it is fixed.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

* Call error function on rethrow after trace exit.
* Fix handling of errors during snapshot restore.

Part of #7230

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump

Commit ed16c1e5 ("build: fix bundled
libcurl and c-ares build on OS X") fixed building libcurl with ares by
adding a dependency on libresolv for Mac OS X. It was forgotten to add
libresolv to check-dependencies exceptions for static build. Do this now.

NO_DOC=CI stuff
NO_TEST=CI stuff
NO_CHANGELOG=CI stuff

Integrate Matthew Haggerty's patches silencing a bunch of gcc build
warnings.

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

Previous version was an intermediate one - 1.15.0-35

The update brings a bunch of CVE fixes:
 * CVE-2020-14354 fixed in c-ares 1.16.1
 * CVE-2020-8277 fixed in c-ares 1.17.0
 * CVE-2021-3672 fixed in c-ares 1.17.2

And a bunch of other security fixes

NO_DOC=build
NO_TEST=build
NO_CHANGELOG=build

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

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

NO_DOC=build
NO_TEST=build

The static build for Linux leans on glibc provided iconv functions. On
Mac OS it links GNU libiconv statically. This patch updates the libiconv
version from 1.16 (released in 2019) to 1.17 (released in 2022).

It is just regular maintenance update. No behaviour changes are
expected. The libiconv 1.17 changelog (see the NEWS file in the archive)
does not mention anything that may have influence on behavior of
tarantool's iconv built-in module.

NO_DOC=no user-visible changes
NO_TEST=no user-visible changes
NO_CHANGELOG=no user-visible changes

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

When I bumped ZSTD (see the next commit), Fedora 34, 35, 36 workflows
started to fail with the following error:

NO_WRAP
In function ‘txn_commit_ro_stmt’,
    inlined from ‘box_select’ at /build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/box.cc:2569:20:
/build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/txn.h:812:32: error: ‘svp.region’ may be used uninitialized [-Werror=maybe-uninitialized]
  812 |                 region_truncate(svp->region, svp->region_used);
      |                                ^
/build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/box.cc: In function ‘box_select’:
/build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/box.cc:2523:33: note: ‘svp.region’ was declared here
 2523 |         struct txn_ro_savepoint svp;
      |                                 ^
In function ‘txn_commit_ro_stmt’,
    inlined from ‘box_select’ at /build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/box.cc:2569:20:
/build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/txn.h:812:32: error: ‘svp.region_used’ may be used uninitialized [-Werror=maybe-uninitialized]
  812 |                 region_truncate(svp->region, svp->region_used);
      |                                ^
/build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/box.cc: In function ‘box_select’:
/build/usr/src/debug/tarantool-2.11.0~entrypoint.306.dev/src/box/box.cc:2523:33: note: ‘svp.region_used’ was declared here
 2523 |         struct txn_ro_savepoint svp;
      |                                 ^
NO_WRAP

This is clearly a false-positive error, because we initialize and use
txn_ro_savepoint iff txn == NULL. Interestingly, we use txn_ro_savepoint
in exactly the same way in box_index_get, but get no error there. Looks
like a compiler bug. I failed to reproduce the issue locally in a Docker
container.

Let's suppress this false-positive error by always initializing
txn_ro_savepoint in txn_begin_ro_stmt - it's cheap.

NO_DOC=compilation fix
NO_TEST=compilation fix
NO_CHANGELOG=compilation fix

GitHub shuts down the macos-10.15 virtual environments [1] and
the bug [2] is fixed. So it's time to move the OSX static build
testing to a newer environment.

[1] https://github.com/actions/virtual-environments/issues/5583
[2] https://github.com/tarantool/tarantool/issues/7459

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

Without `-isysroot <SDK_PATH>` the build fails:

```
/Library/Developer/CommandLineTools/usr/bin/make[4]: Making `all' in   \
    `makeconv'
/Library/Developer/CommandLineTools/usr/bin/c++ -O2 -W -Wall -pedantic \
    -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11          \
    -Wno-ambiguous-reversed-operator     -o ../../bin/makeconv         \
    gencnvex.o genmbcs.o makeconv.o ucnvstat.o -L../../lib -licutu     \
    -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata         \
    -licudata -lpthread -lm
ld: library not found for -lpthread
clang: error: linker command failed with exit code 1 (use -v to see    \
    invocation)
```

ICU is written on C++, so we should pass `CXXFLAGS`, not only `CFLAGS`.

Note: `CPPFLAGS` stands for C preprocessor flags, not C++ flags.

Fixes #7459

NO_DOC=it fixes a build failure for one of build types, nothing to
       document
NO_TEST=it will be tested in a next commit by enabling corresponding
        GitHub Action workflow

Patch updates libyaml to the version that contains fixes of stack
overflows [1]. PR in upstream with original patch: "Avoid recursion in
the document loader" [2].

1. https://github.com/yaml/libyaml/issues/107
2. https://github.com/yaml/libyaml/pull/127

NO_DOC=internal
NO_TEST=internal

This is just regular update to bring bugfixes and improvements in the
library into tarantool.

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

NO_DOC=there is no known behavior changes, consider the change as not
       visible for a user
NO_TEST=there is no specific problem we want to solve and verify here
NO_CHANGELOG=see NO_DOC

- Run the workflow in tarantool/tarantool repo only
- Fix the condition to compose PR title prefix
- Add a small description for created PRs

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

Just regular update to bring readline security fixes into tarantool.

Added a patch to fix file descriptor leak with zero-length history file.

Source of patch: https://ftp.gnu.org/gnu/readline/readline-8.0-patches/
Announcement: https://lists.gnu.org/archive/html/bug-readline/2019-08/msg00004.html

NO_TEST=security update of a dependency
NO_DOC=security update of a dependency

Just regular update to bring ncurses security fixes into tarantool.

New version brings a number of functional and security fixes:
- ncurses 6.3 before patch 20220416 has an out-of-bounds read and
segmentation violation in convert_strings in tinfo/read_entry.c in the
terminfo library (CVE-2022-29458).
- ncurses through v6.2-1. _nc_captoinfo in captoinfo.c has a heap-based
buffer overflow (CVE-2021-39537).

CVE-2022-29458 Detail: https://nvd.nist.gov/vuln/detail/CVE-2022-29458
CVE-2021-39537 Detail: https://nvd.nist.gov/vuln/detail/CVE-2021-39537
Release announcement: https://lists.gnu.org/archive/html/bug-ncurses/2022-07/msg00008.html

NOTE: Build system uses a link to tarball on a local storage instead of
official mirror [1].

1. https://invisible-mirror.net/archives/ncurses/current/

NO_TEST=security update of a dependency
NO_DOC=security update of a dependency

This is a backport of commit
https://github.com/postgres/postgres/commit/9d6077abf9d6efd992a59f05ef5aba981ea32096

It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating.  This method guarantees
that no more than log2(N) levels of recursion can be needed.  However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition.  In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow.  Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting.  Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.

NO_DOC=bug fix
NO_TEST=backport

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

Bump tarantool submodule in tarantool-ee via pull requests:

* tarantool@master -> tarantool-ee@TarantoolBot/update-tarantool-master
* tarantool@2.10 -> tarantool-ee@TarantoolBot/update-tarantool-2.10

If there is an open PR already, it will be updated every time when
a new commit is pushed to tarantool@master or tarantool@2.10.

NO_DOC=ci
NO_TEST=ci
NO_CHANGELOG=ci

Closes tarantool/tarantool-ee#175

In most cases, NaN was treated as NULL. But in case NaN was returned as
a result of a Lua or C user defined function, it was considered a
double. After this patch, NaN will also be considered NULL in the
specified cases.

Closes #6374
Closes #6572

NO_DOC=bugfix

This patch makes the is_res_neg flag false in the sql_rem_int() function
if the left value is negative and the result is 0. Prior to this patch,
the value of the flag was true, which resulted in an assertion during
encoding 0 as MP_INT.

Closes #6575

NO_DOC=bugfix