* LJ_GC64: Fix lua_concat(). Part of #8825 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

The option --sync was ignored due to a misprint. The temporary dir was never removed, overflowing the /tmp by default. NO_TEST=test update NO_DOC=test update NO_CHANGELOG=test update

This test is no longer needed in the Tarantool test suite since it was added to LuaJIT's test suite along with the fix for the issue mentioned in #3060 in scope of #8825 in commit tarantool/luajit@7b98314e0dacc7313c061aceeb0a32afd4e8cbce. Closes #3060 Related to #8825 NO_DOC=Cleanup NO_TEST=Already included in LuaJIT bump NO_CHANGELOG=Already included in LuaJIT bump

Currently, the lua_call privilege simply doesn't work for registered functions. This patch fixes this issue: now, it grants access to any registered function that is written in Lua unless it's a built-in function, such as dostring, or a persistent function. Note, this patch renames access_check_call to access_check_lua_call to avoid confusion because this function is now global. It also renames access_check_eval to access_check_lua_eval for consistency. Closes #9363 NO_DOC=updated doc ticket manually NO_CHANGELOG=feature has not been released yet

Prior to this patch a bunch of illegal conditions was possible: 1. The joinability of a fiber could be changed while the fiber is being joined by someone. This could lead to double recycling: the first one happened on the fiber finish, and the second one in the fiber join. 2. The joinability of a dead joinable fiber could be altered, this led to inability jo join the dead fiber and free its resources. 3. A running fiber could be joined concurrently by two or more fibers, so the fiber could be recycled more than once (once per each concurrent join). 4. A dead recycled fiber could be made joinable and joined leading to the double recycle. Fixed these issues by adding a new FIBER_JOIN_BEEN_INVOKED flag: now the `fiber_set_joinable` and `fiber_join_timeout` functions detect the double join. Because of the API limitations both of them panic when an invalid condition is met: - The `fiber_set_joinable` was not designed to report errors. - The `fiber_join_timeout` can't raise any error unless a timeout is met, because the `fiber_join` users don't expect to receive any error from this function at all (except the one generated by the joined fiber). It's still possible that a fiber join is performed on a struct which has been recycled and, if the new fiber is joinable too, this can't be detected. The current fiber API does not allow to fix this, so this is to be the user's responsibility, they should be warned about the fact the double join to the same fiber is illegal. Closes #7562 @TarantoolBot document Title: `fiber_join`, `fiber_join_timeout` and `fiber_set_joinable` behave differently now. `fiber_join` and `fiber_join_timeout` now panic in case if double join of the given fiber is detected. `fiber_set_joinable` now panics if the given fiber is dead or is joined already. This prevents some amount of error conditions that could happen when using the API in an unexpected way, including: - Making a dead joinable fiber non-joinable could lead to a memory leak: one can't join the fiber anymore. - Making a dead joinable fiber joinable again is a sign of attempt to join the fiber later. That means the fiber struct may be joined later, when it's been recycled and reused. This could lead to a very hard to debug double join. - Making an alive joined fiber non-joinable would lead to the double free: once on the fiber function finish, and secondly in the active fiber join finish. Risks of making it joinable are described above. - Making a dead and recycled fiber joinable allowed to join the fiber once again leading to a double free. Any given by the API `struct fiber` should only be joined once. If a fiber is joined after the first join on it has finished the behavior is undefined: it can either be a panic or an incidental join to a totally foreign fiber.

Setting a box.cfg option to inf or nan can result in a crash or invalid behavior. For example, setting `box.cfg.checkpoint_interval` to 0/0 triggers an assertion failure. Let's add a check against inf and nan for all options. These special numbers don't make any sense as configuration option values anyway. Closes #4962 NO_DOC=bug fix

Since our SQL statistics are disabled, this field is no longer required. Closes #9343 NO_DOC=refactoring NO_TEST=refactroring NO_CHANGELOG=refactoring

There is only one place where the field is filled with other then 0. Still, there is only two possible options, one of them is 0, the other is default value. Let's use them without filling the field. NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring

Prior to this patch only the flags given by the CMAKE_C_FLAGS were shown in the tarantool -v and Lua's tarantool.build.flags. Make it also show the flags from CMAKE_C_FLAGS_<CONFIG> and CFLAGS_LTO variables. The first one is config-specific set of flags (different for Debug, Release, RelWithDebInfo and MinSizeRel configs), the former is set in the cmake/lto.cmake if LTO is enabled. Closes #8022 NO_DOC=build

Currently, BOX_SPACE_MAX equals BOX_ID_NIL, which is used as an error indicator in the box C API. As a result, if box_space_id_by_name() returns BOX_ID_NIL, it's impossible to figure out whether there's no space with the give name or the space exists and has the id equal to BOX_SPACE_MAX. Let's decrement BOX_SPACE_MAX to fix this issue. Since this may break recovery, let's also introduce the new compatibility module option `box_space_max` to allow the user revert to the old behavior. Closes #9118 @TarantoolBot document Title: Document `compat.box_space_max` Please create an entry for the new compatibility module option at https://tarantool.io/compat/box_space_max. `compat.box_space_max` sets the max space id (`box.schema.SPACE_MAX`). The old limit is 2147483647. The new limit is 2147483646. The limit was decremented because the old value is used as an error indicator in the box C API (it equals `BOX_ID_NIL`).