Two things we need to do to fix build with OpenSSL 3.0:

1. Use EVP_MAC_* functions instead of HMAC_*
   https://www.openssl.org/docs/man3.0/man3/HMAC_CTX_new.html

2. Load the Legacy provider to enable legacy algorithms, such as MD4
   https://wiki.openssl.org/index.php/OpenSSL_3.0#Programming_in_OpenSSL_3.0

Closes #6477

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

(cherry picked from commit e3bf73c8)

openssl_err_str is used for reporting OpenSSL errors. It calls
crypto_ERR_* functions using FFI. There's a typo in the code:
ffi.crypto_ERR_error_string is used instead of ffi.C.*.

We don't normally step on this, because OpenSSL doesn't return errors
in our configuration, but if it did for some reason (e.g. a cipher was
disabled in the library), we'd get a confusing error message.

NO_DOC=bug fix
NO_TEST=occur only on internal error
NO_CHANGELOG=occur only on internal error

(cherry picked from commit f72662c5)

After unhiding all internal symbols([1]) we experience a bunch of
problems ([2], [3]). The second one (clash of symbols from different version
of the "small" library) still have no good solution.
You can find more on the topic [4].

The situation for tarantool executable is the same as for any other library.
A library should expose only its public API and should not increase probability
of hard to debug problems due to clash of a user's code with an internal name
from the library.

Let's hide all symbols by default and create a list of exported symbols.
(In fact, this patch is a revert of the patch
03790ac5 ([5]) taking into account the changes
made to the code)

Explanation of adding some controversial symbols to the export list:

* The following symbols are used in shared libraries used in tests
  ("cfunc*.so", "sql_uuid.so", "gh-6024-funcs-return-bin.so", "function1.so",
  "gh-5938-wrong-string-length.so", "module_api.so")

    mp_check
    mp_encode_array
    mp_encode_bin
    mp_encode_bool
    mp_encode_int
    mp_encode_map
    mp_encode_nil
    mp_encode_str
    mp_encode_uint
    mp_decode_array_slowpath
    mp_decode_str
    mp_next_slowpath
    mp_load_u8
    mp_next
    mp_sizeof_array
    mp_sizeof_str
    mp_type_hint
    decimal_from_string

* These symbols are used in "crypto.lua" and, if absent, will lead to the
  failure of the "static_build_cmake_linux" on CI (the crypto prefix was
  used to avoid the clashes of names)

    crypto_ERR_error_string
    crypto_ERR_get_error
    crypto_EVP_DigestInit_ex
    crypto_EVP_DigestUpdate
    crypto_EVP_DigestFinal_ex
    crypto_EVP_get_digestbyname
    crypto_HMAC_Init_ex
    crypto_HMAC_Update
    crypto_HMAC_Final

* For correct work of "schema.lua" in the "static_build_cmake_linux"

    rl_get_screen_size

* The following symbols are used in "ssl-cert-paths-discover.test.lua"
  (I think these symbols will have to be wrapped in the to avoid clashes
  problems)

    X509_get_default_cert_dir_env
    X509_get_default_cert_file_env
    ssl_cert_paths_discover

From "exports.test.lua" have been removed ZSTD symbols checking (see [6]) and
"tt_uuid_str" (see [7]).

1. https://github.com/tarantool/tarantool/issues/2971
2. https://github.com/tarantool/tarantool/issues/5001
3. https://github.com/tarantool/memcached/issues/59
4. https://lists.tarantool.org/pipermail/tarantool-discussions/2020-September/000095.html
5. https://github.com/tarantool/tarantool/commit/03790ac5510648d1d9648bb2281857a7992d0593
6. https://github.com/tarantool/tarantool/issues/4225
7. https://github.com/tarantool/tarantool/commit/acf8745ed8fef47e6d1f1c31708c7c9d6324d2f3

Part of #5932

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

Part of #4681

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

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

Encryption with an arbitrary algorithm and any mode with a
configurable private key.

Closes #3234

Lua, which suffers from lack of ability to pass values by
pointers into FFI functions, nor has an address operator '&' to
take an address of integer or char or anything. Because of that
a user need to either use ffi.new(type[1]) or use static buffer,
but for such small allocations they are both too expensive and
aggravate GC problem.

Now buffer module provides preallocated basic types to use in FFI
functions. The commit is motivated by one another place where
ffi.new('int[1]') appeared, in SWIM module, to obtain payload
size as an out parameter of a C function.

crypto.lua is a public module using OpenSSL directly. But now
lib/crypto encapsulates OpenSSL with additional checks and
similar but more conforming API. It allows to replace OpenSSL
cipher in crypto.lua with lib/crypto methods.

Tarantool has a strict rule for naming methods of libraries - use
the library name as a prefix. For crypto lib methods it should be
'crypto_', not 'tnt_'.

SHA-0 is considered weak for years and was removed in OpenSSL since
1.1.0.

These Lua functions did not work since 15ed10e4, but give 'Digest
method "sha" is not supported' error for any input. Removed them to
don't confuse a user with a Tab completion.

Follow up #1722.
Fixes #4028.

* Add string.hex() method
* Add hmac.*_hex to crypto.lua
* Update crypto/digest to use string.hex()

Closes #2510

Closes #725

Raise an error for non-string arguments instead of trying to
handle digest.crc32(12345LL) as digest.crc32('12345LL')

This is a breaking change.

Fixes #1561