Fix C file generation in jit.bcsave. Add 'cc' file type for saving bytecode. test: set dependencies in BuildTestCLib macro Part of #9145 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump NO_CHANGELOG=LuaJIT submodule bump

There are two reasons for this changeset: * The positive one: Tarantool supports -b and -j options to use LuaJIT modules since the commit bf8b76a4dfc9dd62d4131e90e2ae5d83843b6630 ("lua: proxy -j and -b flags"), so the related tests from lua-Harness suite can be partially (since -O option is still not implemented in Tarantool) enabled. * The negative one: Tarantool diff-based tests for CLI interfaces are hard to maintain, if any change occurs in LuaJIT modules, since the aforementioned tests implement dumb comparison of the output, produced by the current CLI version against the expected one, managed by the .result file. Hence, to rule the tests related to the LuaJIT CLI interface in a more convenient way, the corresponding tests should be moved from the tests in the Tarantool repository to the tests in the LuaJIT repository. The recent LuaJIT bump landed to the master in the scope of commit 0dcf675952fbb76d8cfb6de30b680451d56cdf43 ("luajit: bump new version") enables the nice checks implemented in the lua-Harness suite; this patch removes the barely maintainable diff-based tests from this repository. Follows up #5541 NO_DOC=test NO_CHANGELOG=test

* cmake: introduce AddTestLib macro * test: prepare lauxilarily libs for LuaJIT-tests * test: separate LuaJIT helpers from ffi_util.inc * test: enable <ffi_arith_ptr.lua> in LuaJIT-tests * test: enable <ffi_bitfield.lua> in LuaJIT-tests * test: enable <ffi_call.lua> in LuaJIT-tests * test: enable <ffi_callback.lua> in LuaJIT-tests * test: enable <ffi_const.lua> in LuaJIT-tests * test: enable <ffi_convert.lua> in LuaJIT-tests * test: enable <ffi_enum.lua> in LuaJIT-tests * test: enable <ffi_gcstep_recursive.lua> * test: enable <ffi_jit_arith.lua> in LuaJIT-tests * test: enable <ffi_jit_call.lua> in LuaJIT-tests * test: enable <ffi_jit_conv.lua> in LuaJIT-tests * test: enable <ffi_lex_number.lua> in LuaJIT-tests * test: enable <ffi_metatype.lua> in LuaJIT-tests * test: enable <ffi_new.lua> in LuaJIT-tests * test: enable <ffi_parse_array.lua> in LuaJIT-tests * test: enable <ffi_parse_basic.lua> in LuaJIT-tests * test: enable <ffi_parse_cdef.lua> in LuaJIT-tests * test: enable <ffi_parse_struct.lua> LuaJIT test * test: enable <ffi_tabov.lua> LuaJIT test * test: enable <lightud.lua> LuaJIT test * test: enable <api_call.lua> LuaJIT test * test: enable <catch_wrap.lua> LuaJIT test * test: enable <catch_cpp.lua> LuaJIT test * test: introduce routine to build error message * test: enable CLI-related lua-Harness tests back Closes #7834 Part of #9398 Follows up #5541 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump NO_CHANGELOG=add new tests

We assume that if the new format can store tuples matching the old format, we can update the space format without calling the engine check_format callback. This is true for both memtx and vinyl but not for memcs (EE), which doesn't support extending field types (e.g. changing int16 to int32). Let's call the engine check_format callback unconditionally and let it decide whether tuple format checking can be skipped. Needed for tarantool/tarantool-ee#694 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring

In the commit 22d507d5e968 ("iproto: don't hang on uncancellable iproto request") we used TEST_BUILD define which is absent, we only have a CMake build option with such name. Let's add a define too. While at it let's also show this flag in the `tarantool.build` table. Follow-up #8423 @TarantoolBot document Title: new tarantool.build.test_build flag It is `true` if `TEST_BUILD` build option is set and `false` otherwise.

We need to handle case of dropping new connection. When net_send_greeting() is executed the connection can be closed due to iproto_drop_connections() call. Note that in the test the Tarantool crashes for another reason. Due to access after sleep to the connection that is destroyed so its memory is poisoned. Yet we visit net_send_greeting() too in the test with patch so original issue is verified too. We also need to test that such a connection is closed. This will be done in EE version. Closes #9717 NO_DOC=bugfix

Suppose an error has a cause with some payload fields, for example: local e1 = box.error.new{'e1', foo = 'bar'} -- cause local e2 = box.error.new{'e2', prev = e1} -- effect Now it is possible to access cause payload fields via e2 directly: e2.foo -- 'bar' While looking for a payload field with a given name, we always stop at the topmost (closest to the effect) field. If there's a field with the same name deeper in the stack it is masked. Closes #9106 @TarantoolBot document Title: Document inheritance of error payload fields Product: Tarantool Since: 3.1 Root document: https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_error/error_object/ [Link to the design document](https://www.notion.so/tarantool/Error-subsystem-improvements-90faa0a4714b4143abaf8bed2c10b2fc?pvs=4#c080fe2ac28b46c8b0eda7234a8852ce)

With commit eb2c6a4a4de8 ("box/lua: allow to set custom error payload fields") it is possible to add a field named "raise", but it will override the `error_object:raise()' method. Forbid it. The user can still access masked payload fields through the `unpack()' method. NO_DOC=unreleased NO_CHANGELOG=unreleased

At last we can drop usage of pthread_cancel and associated functions. And remove related leak suppressions. Let's keep memory protection disabling under ASAN. Otherwise leak sanitizer may misbehave on Tarantool panic as below. ``` # Tracer caught signal 11: addr=0x705236d1e000 pc=0x57b7605b10d0 sp=0x705232a00ca0\ # ==1022907==LeakSanitizer has encountered a fatal error.\ # ==1022907==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1\ # ==1022907==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)", ``` Let's also add missing pipe/endpoint destroy in wal while at it. Close #8423 NO_CHANGELOG=internal NO_DOC=internal

In the commit d40ce0fa028a ("core: disable fibers creation after shutdown started") we disable creation of new fibers in the process of shutdown. This may cause subsystem shutdown hanging. The thing is we need fiber pool working during shutdown. For example vinyl engine uses it through "tx" endpoint. Fibers in the pool are finished after idle timeout. So we may have a situation when there is no idle fibers in the pool and we cannot create a new one. Part of #8423 NO_CHANGELOG=bugfix for unreleased version NO_DOC=bugfix for unreleased version