In Lua swim object's method member_by_uuid() could crash if called
with no arguments. UUID was then passed as NULL, and dereferenced.

The patch makes member_by_uuid() treat NULL like nil UUID and
return NULL (member not found). The reason is that
swim_member_by_uuid() can't fail. It can only return a member or
not. It never sets a diag error.

Closes #5951

The key difference between lbox_encode_tuple_on_gc() and
luaT_tuple_encode() is that the latter never raises a Lua error, but
passes an error using the diagnostics area.

Aside of the tuple leak, the patch fixes fiber region's memory 'leak'
(till fiber_gc()). Before the patch, the memory that is used for
serialization of the key is not freed (region_truncate()) when the
serialization fails. It is verified in the gh-5388-<...> test.

While I'm here, added a test case that just verifies correct behaviour
in case of a key serialization failure (added into key_def.test.lua).
The case does not verify whether a tuple leaks and it is successful as
before this patch as well after the patch. I don't find a simple way to
check the tuple leak within a test. Verified manually using the
reproducer from the linked issue.

Fixes #5388

As a follow-up to the previous patch, let's check also emptiness of the
vylog being removed. During vylog rotation all entries are squashed
(e.g. "delete range" annihilates "insert range"), written to the new
vylog and at the end of new vylog SNAPSHOT marker is placed. If the last
entry in the vylog is SNAPSHOT, we can safely remove it without
hesitation.  So it is OK to remove it even during casual recovery
process. However, if it contains rows after SNAPSHOT marker, removal of
vylog may cause data loss. In this case we still can remove it only in
force_recovery mode.

Follow-up #5823

Having data in different engines checkpoint process is handled this way:
 - wait_checkpoint memtx
 - wait_checkpoint vinyl
 - commit_checkpoint memtx
 - commit_checkpoint vinyl

In contrast to commit_checkpoint which does not tolerate fails (if
something goes wrong e.g. renaming of snapshot file - instance simply
crashes), wait_checkpoint may fail. As a part of wait_checkpoint for
vinyl engine vy_log rotation takes place: old vy_log is closed and new
one is created. At this moment, wait_checkpoint of memtx engine has
already created new *inprogress* snapshot featuring bumped vclock.
While recovering from this configuration, vclock of the latest snapshot
is used as a reference.

At the initial recovery stage (vinyl_engine_begin_initial_recovery),
we check that snapshot's vclock matches with vylog's one (they should be
the same since normally vylog is rotated along with snapshot). On the
other hand, in the directory we have old snapshot and new vylog (and new
.inprogress snapshot). In such a situation recovery (even in force mode)
was aborted. The only way to fix this dead end, user has to manually
delete last vy_log file.

Let's proceed with the same resolution while user runs force_recovery
mode: delete last vy_log file and update vclock value. If user uses
casual recovery, let's print verbose message how to fix this situation
manually.

Closes #5823

Prior to this patch string passed to user-defined Lua-function from SQL
was cropped in case it contains '\0'. At the same time, it wasn't
cropped if it is passed to the function from BOX. After this patch the
string won't be cropped when passed from SQL if it contain '\0'.

Closes #5938

Prior to this patch string passed to user-defined C-function from SQL
was cropped in case it contains '\0'. At the same time, it wasn't
cropped if it is passed to the function from BOX. Now it isn't cropped
when passed from SQL.

Part of #5938

Once simple bootstrap is complete and there is no
replicas used we should run with gc unpaused.

Part-of #5806

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

Part-of #5806

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

In case if replica managed to be far behind the master node
(so there are a number of xlog files present after the last
master's snapshot) then once master node get restarted it
may clean up the xlogs needed by the replica to subscribe
in a fast way and instead the replica will have to rejoin
reading a number of data back.

Lets try to address this by delaying xlog files cleanup
until replicas are got subscribed and relays are up
and running. For this sake we start with cleanup fiber
spinning in nop cycle ("paused" mode) and use a delay
counter to wait until relays decrement them.

This implies that if `_cluster` system space is not empty
upon restart and the registered replica somehow vanished
completely and won't ever come back, then the node
administrator has to drop this replica from `_cluster`
manually.

Note that this delayed cleanup start doesn't prevent
WAL engine from removing old files if there is no
space left on a storage device. The WAL will simply
drop old data without a question.

We need to take into account that some administrators
might not need this functionality at all, for this
sake we introduce "wal_cleanup_delay" configuration
option which allows to enable or disable the delay.

Closes #5806

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

@TarantoolBot document
Title: Add wal_cleanup_delay configuration parameter

The `wal_cleanup_delay` option defines a delay in seconds
before write ahead log files (`*.xlog`) are getting started
to prune upon a node restart.

This option is ignored in case if a node is running as
an anonymous replica (`replication_anon = true`). Similarly
if replication is unused or there is no plans to use
replication at all then this option should not be considered.

An initial problem to solve is the case where a node is operating
so fast that its replicas do not manage to reach the node state
and in case if the node is restarted at this moment (for various
reasons, for example due to power outage) then `*.xlog` files might
be pruned during restart. In result replicas will not find these
files on the main node and have to reread all data back which
is a very expensive procedure.

Since replicas are tracked via `_cluster` system space this we use
its content to count subscribed replicas and when all of them are
up and running the cleanup procedure is automatically enabled even
if `wal_cleanup_delay` is not expired.

The `wal_cleanup_delay` should be set to:

 - `0` to disable the cleanup delay;
 - `>= 0` to wait for specified number of seconds.

By default it is set to `14400` seconds (ie `4` hours).

In case if registered replica is lost forever and timeout is set to
infinity then a preferred way to enable cleanup procedure is not setting
up a small timeout value but rather to delete this replica from `_cluster`
space manually.

Note that the option does *not* prevent WAL engine from removing
old `*.xlog` files if there is no space left on a storage device,
WAL engine can remove them in a force way.

Current state of `*.xlog` garbage collector can be found in
`box.info.gc()` output. For example

``` Lua
 tarantool> box.info.gc()
 ---
   ...
   is_paused: false
```

The `is_paused` shows if cleanup fiber is paused or not.

* Remove unnecessary `#include "tt_static.h"` from
  src/ssl_cert_paths_discover.c
* Fix typo at test/app-tap/ssl-cert-paths-discover.test.lua
  call `os.exit` instead of `os:exit`

A follow up on #5615

Found that in case of exiting the rope_insert function with an error
some nodes are created but not deleted.

This commit fixes it and adds the test.

Test checks  that in case of this error the number of
allocated nodes and the number of freed nodes are the same.

Closes #5788

Lua buffer module used to have a couple of preallocated objects of
type 'union c_register'. It was a bunch of C scalar and array
types intended for use instead of ffi.new() where it was needed to
allocate a temporary object like 'int[1]' just to be able to pass
'int *' into a C function via FFI.

It was a bit faster than ffi.new() even for small sizes. For
instance (when JIT works), getting a register to use it as
'int[1]' cost around 0.2-0.3 ns while ffi.new('int[1]') costs
around 0.4 ns. Also the code looked cleaner.

But Lua registers were global and therefore had the same issue as
IBUF_SHARED and static_alloc() in Lua - no ownership, and sudden
reuse when GC starts right the register is still in use in some
Lua code. __gc handlers could wipe the register values making the
original code behave unpredictably.

IBUF_SHARED was fixed by proper ownership implementation, but it
is not necessary with Lua registers. It could be done with the
buffer.ffi_stash_new() feature, but its performance is about 0.8
ns which is worse than plain ffi.new() for simple scalar types.

This patch eliminates Lua registers, and uses ffi.new() instead
everywhere.

Closes #5632

Static_alloc() uses a fixed size circular BSS memory buffer. It is
often used in C when need to allocate something of a size smaller
than the static buffer temporarily. And it was thought that it
might be also useful in Lua when backed up by ffi.new() for large
allocations.

It was useful, and faster than ffi.new() on sizes > 128 and less
than the static buffer size, but it wasn't correct to use it. By
the same reason why IBUF_SHARED global variable should not have
been used as is. Because without a proper ownership the buffer
might be reused in some unexpected way.

Just like with IBUF_SHARED, the static buffer could be reused
during Lua GC in one of __gc handlers. Essentially, at any moment
on almost any line of a Lua script.

IBUF_SHARED was fixed by proper ownership implementation, but it
is not possible with the static buffer. Because there is no such a
thing like a static buffer object which can be owned, and even if
there would be, cost of its support wouldn't be much better than
for the new cord_ibuf API. That would make the static buffer close
to pointless.

This patch eliminates static_alloc() from Lua, and uses cord_ibuf
instead almost everywhere except a couple of places where
ffi.new() is good enough.

Part of #5632

static_alloc() appears not to be safe to use in Lua, because it
does not provide any ownership protection for the returned values.

The problem appears when something is allocated, then Lua GC
starts, and some __gc handlers might also use static_alloc(). In
Lua and in C - both lead to the buffer being corrupted in its
original usage place.

The patch is a part of activity of getting rid of static_alloc()
in Lua. It removes it from uri Lua module and makes it use the
new FFI stash feature, which helps to cache frequently used and
heavy to allocate FFI values.

In one place static_alloc() was used for an actual buffer - it was
replaced with cord_ibuf which is equally fast when preallocated.

ffi.new() for temporary struct uri is not used, because

- It produces a new GC object;

- ffi.new('struct uri') costs around 20ns while FFI stash
  costs around 0.8ns. The hack with 'struct uri[1]' does not help
  because size of uri is > 128 bytes;

- Without JIT ffi.new() costs about the same as the stash, not
  better as well;

The patch makes uri perf a bit better in the places where
static_alloc() was used, because its cost was around 7ns for one
allocation.

The function converts struct tt_uuid * to a string. The string is
allocated on the static buffer, which can't be used in Lua due to
unpredictable GC behaviour. It can start working any moment even
if tt_uuid_str() has returned, but its result wasn't passed to
ffi.string() yet. Then the buffer might be overwritten.

Lua uuid now uses tt_uuid_to_string() which does the same but
takes the buffer pointer. The buffer is stored in an ffi stash,
because it is x4 times faster than ffi.new('char[37]') (where 37
is length of a UUID string + terminating 0) (2.4 ns vs 0.8 ns).

After this patch UUID is supposed to be fully compatible with Lua
GC handlers.

Part of #5632

The global ibuf used for hot Lua and Lua C code didn't have
ownership management. As a result, it could be reused in some
unexpected ways during Lua GC via __gc handlers, even if it was
currently in use in some code below the stack.

The patch makes cord_ibuf_take() steal the global buffer from its
global stash, and assign to the current fiber. cord_ibuf_put()
puts it back to the stash, and detaches from the fiber. If yield
happens before cord_ibuf_put(), the buffer is detached
automatically.

Fiber attach/detach is done via on_yield/on_stop triggers. The
buffer is not supposed to survive a yield, so this allows to
free/put the buffer back to the stash even if the owner didn't do
that. For instance, if a Lua exception was raised before
cord_ibuf_put() was called.

This makes cord buffer being safe to use in any yield-free code,
even if Lua GC might be started. And in non-Lua code as well.

Part of #5632

There was a global ibuf object called tarantool_lua_ibuf. It was
used in all the places working with Lua which didn't have yields,
and where fiber's region could be potentially slower due to not
being able to guarantee the allocated memory is contiguous.

Yields during the ibuf usage were prohibited because another fiber
would take the same ibuf and override its previous content which
was still used by another fiber.

But it wasn't taken into account that there is Lua GC. It can be
invoked from any Lua function in Lua C code, and almost on any
line in the Lua scripts. During GC some deleted objects might have
GC handlers installed as __gc metamethods. From the handler they
could call Tarantool functions, including the ones using the
global ibuf.

Therefore ibuf could be overridden not only at yields, but almost
in any moment. Because with the Lua GC at hand, the multitasking
is not strictly "cooperative" anymore.

It is necessary to implement ownership for the global buffer. The
patch prepares the API for this: the buffer is moved to its own
file, and has methods take(), put(), and drop().

Take() is supposed to make the current fiber own the buffer. Put()
makes it available again. Drop() does the same but also clears the
buffer (frees its memory). The ownership itself is a subject for
the next patches. Here only the API is prepared.

The patch "hits" performance a little. Previously the get of
buffer.IBUF_SHARED cost around 1 ns. Now cord_ibuf_take() +
cord_ibuf_put() cost around 5 ns together. The next patches will
make it worse, up to 15 ns until #5871 is done.

Part of #5632

In msgpack test it is used only to check that 'struct ibuf *' can
be passed to encode() functions. But soon IBUF_SHARED will be
deleted, and its alternative won't be yield-tolerant. This means
it can't be used in this test. There are yields between the buffer
usages.

In varbinary test it is used in a too complicated way to be able
to put it back normally. And otherwise its usage does not make
much sense - without put() it is going to be created from the
scratch on non-first usage until a yield.

In the module_api test it is used to check if some function works
with 'struct ibuf *'. Can be done without IBUF_SHARED.

Part of #5632

fio:pread() used buffer.IBUF_SHARED, which might be reused after a
yield. As a result, if pread() was called from 2 different fibers
or in parallel with something else using IBUF_SHARED, it would
turn the buffer into garbage for all parallel usages.

The same problem existed for read(), and was fixed in
c7c24f84 ("fio: Fix race condition
in fio.read"). But apparently pread() was missed.

What is worse, the original commit's test passed even without the
fix from that commit. Because it didn't check the results of
read()s called from 2 fibers.

The patch fixes pread() and adds a test covering both read() and
pread(). The old test from the original commit is dropped.

Follow up #3187

Was caught by base64 test with enabled ASAN.

It also caused data corruption - garbage instead of "extra bits" was
saved into state->result if there was no space in output buffer.

Decode state removed along with helper functions.

Added test for "zero-sized output buffer" case.

Fixes: #3069
(cherry picked from commit 7214add2c7f2a86265a5e08f2184029a19fc184d)

Since the introduction of asynchronous commit, which doesn't wait for a
WAL write to succeed, it's quite easy to clog WAL with huge amounts
write requests. For now, it's only possible from an applier, since it's
the only user of async commit at the moment.

This happens when replica is syncing with master and reads new
transactions at a pace higher than it can write them to WAL (see docbot
request for detailed explanation).

To ameliorate such behavior, we need to introduce some limit on
not-yet-finished WAL write requests. This is what this commit is trying
to do.
A new counter is added to wal writer: queue_size (in bytes) together with a
corresponding configuration setting: `wal_queue_max_size`.
The counter is increased on every new submitted request, and decreased once
the tx thread receives a confirmation that a specific request was written.

Actually, the limit is added to an abstract journal queue, but
currently works only for wal writer, since it's the only possible journal
when applier is working.

Once size reaches its maximum value, applier is blocked until
some of the write requests are finished.

The size limit isn't strict, i.e. if there's at least one free byte, the
whole write request fits and no blocking is involved.

The feature is ready for `box.commit{is_async=true}`. Once it's
implemented, it should check whether the queue is full and let the user
decide what to do next. Either wait or roll the tx back.

Closes #5536

@TarantoolBot document
Title: new configuration option: 'wal_queue_max_size'

`wal_queue_max_size` puts a limit on the amount of concurrent write requests
submitted to WAL.
`wal_queue_max_size` is measured in number of bytes to be written (0
means unlimited, which was the default behaviour before).
The option only affects replica behaviour at the moment, and defaults
to 16 megabytes. The option limits the pace at which replica reads new
transactions from master.

Here's when the option comes in handy:

Before this option was introduced such a situation could be possible:
there are 2 servers, a master and a replica, and the replica is down for
some period of time. While the replica is down, master serves requests
at a reasonable pace, possibly close to its WAL throughput limit. Once the
replica reconnects, it has to receive all the data master has piled up and
there's no limit in speed at which master sends the data to replica, and,
without the option, there was no limit in speed at which replica submitted
corresponding write requests to WAL.

This lead to a situation when replica's WAL was never in time to serve the
requests and the amount of pending requests was constantly growing.
There was no limit for memory WAL write requests take, and this clogging
of WAL write queue could even lead to replica using up all the available
memory.

Now, when `wal_queue_max_size` is set, appliers will stop reading new
transactions once the limit is reached. This will let WAL process all the
requests that have piled up and free all the excess memory.

Implemented on_shutdown API, which allows to register functions
that will be called when the tarantool stopped. Functions will
be called in the reverse order they are registered. So the module
developer registers one fuction that starts module termination and
waits for its competition. This function should be fast or used an
asynchronous waiting mechanism (coio_wait or cord_cojoin for example).

Closes #5723

@TarantoolBot document
Title: Implement on_shutdown API
Implemented on_shutdown API, which allows to register functions
that will be called when the tarantool stopped. Functions will
be called in the reverse order they are registered. So the module
developer registers one fuction that starts module termination and
waits for its competition. This function should be fast or used an
asynchronous waiting mechanism (coio_wait or cord_cojoin for example).

Renamed granularity option to slab_alloc_granularity, according
to the name of the other options for small allocator.

Follow-up #5518

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>

getaddrinfo() is a POSIX function that returns addrinfo structure in
success and error value for the failure.POSIX standard [1]
describes possible error values but description have a status of
recommendation. When non-existent hostname is passed to getaddrinfo() it
fails with error, but error value may be different on Linux and FreeBSD.
We have testcases where we check error messages obtained from
getaddinfo() ignoring this fact and sometime test fails on FreeBSD [2].

1. https://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html
2. https://github.com/tarantool/tarantool/runs/2107188391

Part of #5652

Part of #5652

Response object is a unpacked msgpack structure, returned by Tarantool.
Nor msgpack-python [1] that used in tarantool-python nor msgpack [2]
itself cannot guarantee an order of keys in unpacked dictionaries.
Therefore we have different keys order with running tests under Python 2
and Python 3, for example box-py/call.test.py. To workaround a problem
proposed a conversion of dictionaries in a tuple to lists before
printing Response object.

Requires changes in tarantool-python [3].

1. https://github.com/msgpack/msgpack-python/pull/164
2. https://github.com/msgpack/msgpack/issues/215
3. https://github.com/tarantool/tarantool-python/pull/186

Part of #5652
Follows up #5538

Test output with running on Python 2 and Python 3 is not the same.

[009] box-py/iproto.test.py                                           [ fail ]
[009]
[009] Test failed! Result content mismatch:
[009] --- box-py/iproto.result  Sat Mar 13 17:46:54 2021
[009] +++ /rw_bins/test/var/rejects/box-py/iproto.reject        Sat Mar 13 17:50:51 2021
[009] @@ -29,7 +29,7 @@
[009]  IPROTO_UPDATE
[009]  query {'IPROTO_CODE': 4} {'IPROTO_SPACE_ID': 280}
[009]  True
[009] -query {'IPROTO_CODE': 4} {'IPROTO_SPACE_ID': 280, 'IPROTO_KEY': (1,)}
[009] +query {'IPROTO_CODE': 4} {'IPROTO_KEY': (1,), 'IPROTO_SPACE_ID': 280}
[009]  True
[009]
[009]
[009]
[009] Last 15 lines of Tarantool Log file [Instance "box"][/rw_bins/test/var/009_box-py/box.log]:

1. https://github.com/tarantool/tarantool/pull/5751/checks?check_run_id=2103097418

Part of #5652
Follows up #5538

Part of #5652

Part of #5652

golden100 is an array of int32_t elements. So sizeof(uint64_t)
is exactly double array element size. In other words, only half
of golden100 array is checked. This patch makes calculation of
array size type-independed.

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

The reason why tarantool -e always enters interactive mode is that
statement after option -e isn't considered as a script.

In man PUC-Rio lua there are different names for statement -e (stat)
and script, but they have the same behavior regarding interactive
mode. (Also cases, when interpreter loads stdin, have the same behaviour).

NOTE: test for this code fix uses errinjs, and the last one  should work only
in debug mode, so added `release_disabled` in suite.ini. But there is a bug in
test-run: `release_disable` disables tests at each build type. Partially this
problem is descripted in tarantool/test-run#199.

Fixes #5040

Sometimes, it's useful to set error injections via environment
variables and this commit adds this opportunity.

e.g: `ERRINJ_WAL_WRITE=true tarantool` will be launched with
ERRINJ_WAL_WRITE setted to true.

Errinjs with bool parameters can be set to "true", "false",
"True", "False", "TRUE", "FALSE", etc. (case-insensitive variable).

Errinjs with int or double parameters should be whole valid ("123s" is invalid).
e.g. for int or double: "123", "-1", "2.34", "+2.34".

NOTE: errinjs should work only in debug mode, so added `release_disabled` in
suite.ini. But there is a bug in test-run: `release_disable` disables tests at
each build type. Partially this problem is descripted in tarantool/test-run#199.

Part of #5040

Seems previously "path" wasn't installed to index schema. This
patch fixes it and introduces a test.

Closes #5451

Granularity is an option that allows user to set
multiplicity of memory allocation in small allocator.
Granulatiry must be exponent of two and >= 4. By default
granularity value == sizeof(intptr_t), as it was before,
when this option was not provided.

@TarantoolBot document
Title: Add 'granularity' option to box.cfg{}
Add granularity option that allows user to set multiplicity
of memory allocation in small allocator. Granularity determines
not only alignment of objects, but also size of the objects in
the pool. Thus, the greater the granularity, the greater the
memory loss per one memory allocation, but tuples with different
sizes are allocated from the same mempool, and we do not lose
memory on the slabs, when we have highly distributed tuple sizes.
This is somewhat similar to a large alloc factor. The smaller the
granularity, the less memory loss per allocation, if the user has
many small tuples of approximately the same size, it will be nice
to set granularity == 4 to save memory.

This option must be set once during start, default value
== sizeof(intptr_t) (8 on 64 bit platforms), as it was before, when
this option was not provided. Granularity must be exponent of two
and >= 4. Together with the slab_alloc_factor, this option gives you
full control over the behavior of small allocator.

Closes #5518

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>

The static build isn't as portable as it should be. In fact, the
OPENSSLDIR is configured at build time, but in runtime, it may (and do)
differ:

```
$ strace tarantool -e 'require("http.client").get("https://...")'
...
openat(AT_FDCWD, "/__w/sdk/sdk/build/tarantool/static-build/"
                 "openssl-prefix/ssl/cert.pem", O_RDONLY) =
                 -1 ENOENT (No such file or directory)
...
stat("/__w/sdk/sdk/build/tarantool/static-build/"
     "openssl-prefix/ssl/certs/...", ...) =
     -1 ENOENT (No such file or directory)
...
```

As a result, statically build tarantool can't open some https links with
an error:

```
tarantool> http_client = require('http.client').new({max_connections = 5})
tarantool> http_client:get('https://..../', {verbose = true})
*   Trying X.Y.Z.W:443...
* TCP_NODELAY set
* Connected to .... (X.Y.Z.W) port 443 (#0)
* ALPN, offering http/1.1
* SSL certificate problem: self signed certificate in certificate chain
* Closing connection 0
---
- status: 495
  reason: SSL peer certificate or SSH remote key was not OK
...
```

Also this error may occur at dynamically build tarantool in case of
linkage tarantool binary with incorrectly configured openssl.

In this patch, we adopt the approach from the golang ecosystem [1-3].
At startup, tarantool scans several popular locations and uses it for
`SSL_CERT_DIR` and/or `SSL_CERT_FILE` setting. See also [4,5] - it's
fun.

[1] https://serverfault.com/a/722646
[2] https://golang.org/src/crypto/x509/root_unix.go
[3] https://golang.org/src/crypto/x509/root_linux.go
[4] https://github.com/edenhill/librdkafka/blob/cb69d2a8486344252e0fcaa1f959c4ab2d8afff3/src/rdkafka_ssl.c#L845
[5] https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/



Close #5615

Co-authored-by: Yaroslav Dynnikov <yaroslav.dynnikov@gmail.com>

Closes #5463

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

W611 (A line consists of nothing but whitespace)

Note: changes were made automatically in vim with regexp "%s/^\s*$//g".

Closes #5739

W621 (Inconsistent indentation (SPACE followed by TAB))

Part of #5464