Дмитрий Кольцов authored 1 year ago and Dmitry Ivanov committed 3 months ago

NO_DOC=disable feedback
NO_TEST=disable feedback

godzie44 authored 2 years ago and Dmitry Ivanov committed 3 months ago

- add box_tuple_data_offset function
  (return offset of the msgpack encoded data from the beginning of the tuple)
- add more export functions

NO_DOC=build
NO_TEST=build

Дмитрий Кибирев authored 1 year ago and Dmitry Ivanov committed 3 months ago

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

Виталий Шунков authored 1 year ago and Dmitry Ivanov committed 3 months ago

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

Дмитрий Кибирев authored 1 year ago and Dmitry Ivanov committed 3 months ago

NO_DOC=ci change
NO_TEST=ci change
NO_CHANGELOG=ci change

Виталий Шунков authored 1 year ago and Dmitry Ivanov committed 3 months ago

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

Yaroslav Dynnikov authored 1 year ago and Dmitry Ivanov committed 3 months ago

1. Pass `docker build --build-arg TARANTOOL_VERSION=...` to ensure the
   resulting image contains the correct version.
2. Pass it in the CI trigger variables.
3. Fix CI jobs relationships: "docker" stage needs "deploy-packages".
4. Minor fixes in job names.

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

Alexey Protsenko authored 1 year ago and Dmitry Ivanov committed 3 months ago

Add a trigger to run tarantool-module CI tests when a new docker image
is released (on tag).

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

Alexey Protsenko authored 2 years ago and Dmitry Ivanov committed 3 months ago

- Add test_linux, test_debian_docker_luacheck to .gitlab.ci.yml.
- Add coverage from .travis.mk.
- Sign package on build.
- Add checkpatch linter.
- Add docker image build (tarantool/tarantool from Dockerhub)

NO_DOC=ci change
NO_TEST=ci change
NO_CHANGELOG=ci change

Дмитрий Кольцов authored 1 year ago and Dmitry Ivanov committed 3 months ago

NO_DOC=chore
NO_CHANGELOG=chore
NO_TEST=chore

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

If the write iterator sees that one DELETE statement follows another,
which isn't discarded because it's referenced by a read view, it drops
the newer DELETE, see commit a6f45d87 ("vinyl: discard tautological
DELETEs on compaction"). This is incorrect if the older DELETE is a
deferred DELETE statement (marked as SKIP READ) because such statements
are dumped out of order, i.e. there may be a statement with the LSN
lying between the two DELETEs in an older source not included into this
compaction task. If we discarded the newer DELETE, we wouldn't overwrite
this statement on major compaction, leaving garbage. Fix this issue by
disabling this optimization for deferred DELETEs.

Closes #10895

NO_DOC=bug fix

(cherry picked from commit 2945a8c9fde6df9f6cbc714f9cf8677f0fded57a)

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

vy_lsm.c seems to be a more appropriate place for cache invalidation
because (a) it's vy_lsm that owns the cache and (b) we invalidate
the cache on rollback in vy_lsm_rollback_stmt().

While we are at it, let's inline vy_tx_write() and vy_tx_write_prepare()
because they are trivial and used in just one place.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

(cherry picked from commit 44c245ef0baa227a6bff75de2a91f20da5532dc1)

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

There's no point in doing so because if the committed tuple has been
overwritten by the time it's committed, the statement that overwrote
it must have already invalidated the cache, see `vy_tx_write()`.
The code invalidating the cache on commit was added along with the
cache implementation without any justification.

NO_DOC=minor
NO_TEST=minor
NO_CHANGELOG=minor

(cherry picked from commit 6ee49a5955893834fdaaf554d57d92d3f35992bc)

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

Once a statement is prepared to be committed to WAL, it becomes visible
(in the 'read-committed' isolation level) so it can be added to the
tuple cache. That's why if the statement is rolled back due to a WAL
error, we have to invalidate the cache. The problem is that the function
invalidating the cache (`vy_cache_on_write`) ignores the statement if
it's a DELETE judging that "there was nothing and there is nothing now".
This is apparently wrong for rollback. Fix it.

Closes #10879

NO_DOC=bug fix

(cherry picked from commit d64e29da2c323a4b4fcc7cf9fddb0300d5dd081f)

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

A multikey index stores a tuple once per each entry of the indexed
array field, excluding duplicates. For example, if the array field
equals {1, 3, 2, 3}, the tuple will be stored three times. Currently,
when a tuple with duplicate multikey entries is inserted into a
transaction write set, duplicates are overwritten as if they belonged
to different statements. Actually, this is pointless: we could just as
well skip them without trying to add to the write set. Besides, this
may break the assumptions taken by various optimizations, resulting in
anomalies. Consider the following example:

```lua
local s = box.schema.space.create('test', {engine = 'vinyl'})
s:create_index('primary')
s:create_index('secondary', {parts = {{'[2][*]', 'unsigned'}}})
s:replace({1, {10, 10}})
s:update({1}, {{'=', 2, {10}}})
```

It will insert the following entries to the transaction write set
of the secondary index:

 1. REPLACE {10, 1} [overwritten by no.2]
 2. REPLACE {10, 1} [overwritten by no.3]
 3. DELETE {10, 1} [turned into no-op as REPLACE + DELETE]
 4. DELETE {10, 1} [overwritten by no.5]
 5. REPLACE {10, 1} [turned into no-op as DELETE + REPLACE]

(1-2 correspond to `replace()` and 3-5 to `delete()`)

As a result, tuple {1, {10}} will be lost forever.

Let's fix this issue by silently skipping duplicate multikey entries
added to a transaction write set. After the fix, the example above
will produce the following write set entries:

 1. REPLACE{10, 1} [overwritten by no.2]
 2. DELETE{10, 1} [turned into no-op as REPLACE + DELETE]
 3. REPLACE{10, 1} [committed]

(1 corresponds to `replace()` and 2-3 to `delete()`)

Closes #10869
Closes #10870

NO_DOC=bug fix

(cherry picked from commit 1869dce15d9a797391e45df75507078d91f1651e)

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

A Vinyl read iterator scans all read sources (memory and disk levels)
even if it's executed in a read view from which most of the sources are
invisible. As a result, a long running scanning request may spend most
of the time skipping invisible statements. The situation is exacerbated
if the instance is experiencing a heavy write load because it would pile
up old statement versions in memory and force the iterator to skip over
them after each disk read.

Since the replica join procedure in Vinyl uses a read view iterator
under the hood, the issue is responsible for a severe performance
degradation of the master instance and the overall join procedure
slowdown when a new replica is joined to an instance running under
a heavy write load.

Let's fix this issue by making a read iterator skip read sources that
aren't visible from its read view.

Closes #10846

NO_DOC=bug fix

(cherry picked from commit 6a214e42e707b502022622866d898123a6f177f1)

Vladimir Davydov authored 3 months ago and Dmitry Ivanov committed 3 months ago

Statements executed in a transaction are first inserted into the
transaction write set and only when the transaction is committed, they
are applied to the LSM trees that store indexed keys in memory. If the
same key is updated more than once in the same transaction, the old
version is marked as overwritten in the write set and not applied on
commit.

Initially, write sets of different indexes of the same space were
independent: when a transaction was applied, we didn't have a special
check to skip a secondary index statement if the corresponding primary
index statement was overwritten because in this case the secondary
index statement would have to be overwritten as well. This changed when
deferred DELETEs were introduced in commit a6edd455 ("vinyl:
eliminate disk read on REPLACE/DELETE"). Because of deferred DELETEs,
a REPLACE or DELETE overwriting a REPLACE in the primary index write
set wouldn't generate DELETEs that would overwrite the previous key
version in write sets of the secondary indexes. If we applied such
a statement to the secondary indexes, it'd stay there forever because,
since there's no corresponding REPLACE in the primary index, a DELETE
wouldn't be generated on primary index compaction. So we added a special
instruction to skip a secondary index statement if the corresponding
primary index was overwritten, see `vy_tx_prepare()`. Actually, this
wasn't completely correct because we skipped not only secondary index
REPLACE but also DELETE. Consider the following example:

```lua
local s = box.schema.space.create('test', {engine = 'vinyl'})
s:create_index('primary')
s:create_index('secondary', {parts = {2, 'unsigned'}})

s:replace{1, 1}

box.begin()
s:update(1, {{'=', 2, 2}})
s:update(1, {{'=', 2, 3}})
box.commit()
```

UPDATEs don't defer DELETEs because, since they have to query the old
value, they can generate DELETEs immediately so here's what we'd have
in the transaction write set:

 1. REPLACE {1, 2} in 'test.primary' [overwritten by no.4]
 2. DELETE {1, 1} from 'test.secondary'
 3. REPLACE {1, 2} in 'test.secondary' [overwritten by no.5]
 4. REPLACE{1, 3} in 'test.primary'
 5. DELETE{1, 2} from 'test.secondary'
 6. REPLACE{1, 3} in 'test.secondary'

Statement no.2 would be skipped and marked as overwritten because of
the new check, resulting in {1, 1} never deleted from the secondary
index. Note, the issue affects spaces both with and without enabled
deferred DELETEs.

This commit fixes this issue by updating the check to only skip REPLACE
statements. It should be safe to apply DELETEs in any case.

There's another closely related issue that affects only spaces with
enabled deferred DELETEs. When we generate deferred DELETEs for
secondary index when a transaction is committed (we can do it if we find
the previous version in memory), we assume that there can't be a DELETE
in a secondary index write set. This isn't true: there can be a DELETE
generated by UPDATE or UPSERT. If there's a DELETE, we have nothing to
do unless the DELETE was optimized out (marked as no-op).

Both issues were found by `vinyl-luatest/select_consistency_test.lua`.

Closes #10820
Closes #10822

NO_DOC=bug fix

(cherry picked from commit 6a87c45deeb49e4e17ae2cc0eeb105cc9ee0f413)

Also, remove unreleased/ entries.

NO_DOC=changelog
NO_TEST=changelog
NO_CHANGELOG=changelog

Currently, we use raw index for count operation instead of
`box_index_count`. As a result, we skip a check if current transaction
can continue and we don't begin transaction in engine if needed. So, if
count statement is the first in a transaction, it won't be tracked by
MVCC since it wasn't notified about the transaction. The commit fixes
the mistake. Also, the commit adds a check if count was successful and
covers it with a test.

In order to backport the commit to 2.11, space name was wrapped with
quotes since it is in lower case and addressing such spaces with SQL
without quotes is Tarantool 3.0 feature. Another unsupported feature is
prohibition of data access in transactional triggers - it was used in a
test case so it was rewritten.

Closes #10825

NO_DOC=bugfix

(cherry picked from commit 0656a9231149663a0f13c4be7466d4776ccb0e66)

The test expects at least 10 dumps to be created in 60 seconds. It
usually works but sometimes, when the host is heavy loaded, Vinyl
doesn't produce enough dumps in time and fails the test. On CI the test
usually fails with 7-9 dumps. To avoid flaky failures, let's reduce the
expected dump count down to 5.

Closes #10752

NO_DOC=test fix
NO_CHANGELOG=test fix

(cherry picked from commit 5325abd3441ecb4b589799c32ec181d88724b8a8)

`vy_mem_insert()` and `vy_mem_insert_upsert()` increment the row count
statistic of `vy_mem` only if no statement is replaced, which is
correct, while `vy_lsm_commit()` increments the row count of `vy_lsm`
unconditionally. As a result, `vy_lsm` may report a non-zero statement
count (via `index.stat()` or `index.len()`) after a dump. This may
happen only with a non-unique multikey index, when the statement has
duplicates in the indexed array, and only if the `deferred_deletes`
option is enabled, because otherwise we drop duplicates when we form
the transaction write set, see `vy_tx_set()`. With `deferred_deletes`,
we may create a `txv` for each multikey entry at the time when we
prepare to commit the transaction, see `vy_tx_handle_deferred_delete()`.

Another problem is that `vy_mem_rollback_stmt()` always decrements
the row count, even if it didn't find the rolled back statement in
the tree. As a result, if the transaction with duplicate multikey
entries is rolled back on WAL error, we'll decrement the row count
of `vy_mem` more times than necessary.

To fix this issue, let's make the `vy_mem` methods update the in-memory
statistic of `vy_lsm`. This way they should always stay in-sync. Also,
we make `vy_mem_rollback_stmt()` skip updating the statistics in case
the rolled back statement isn't present in the tree.

This issue results in `vinyl-luatest/select_consistency_test.lua`
flakiness when checking `index.len()` after compaction. Let's make
the test more thorough and also check that `index.len()` equals
`index.count()`.

Closes #10751
Part of #10752

NO_DOC=bug fix

(cherry picked from commit e8810c555d4e6ba56e6c798e04216aa11efb5304)

This commit fixes some cases of upgrading schema from 1.6.9:

1. Fix updating empty password for users. In 1.6 credentials were array
   in _user, in 1.7.5 they became map.

2. Automatically update the format of user spaces. Format of system
   spaces have been properly fixed during upgrade to 1.7.5. However,
   commit 519bc82e ("Parse and validate space formats") introduced
   strict checking of format field in 1.7.6. So, the format of user
   spaces should be also fixed.

Back in 1.6 days, it was allowed to write anything in space format.
This commit only fixes valid uses of format:
    {name = 'a', type = 'number'}
    {'a', type = 'number'}
    {'a', 'num'}
    {'a'}

Invalid use of format (e.g. {{}}, or {{5, 'number'}} will cause error
anyway. User has to fix the format on old version and only after that
start a new one.

This commit also introduces the test, which checks, that we can
properly upgrade from 1.6.9 to the latest versions, at least in basic
cases.

Closes #10180

NO_DOC=bugfix

(cherry picked from commit f69e2ae488b3620e31f1a599d8fb78a66917dbfd)

Bump test-run to new version with the following improvements:

- Fix a typo [1]
- Follow-up fix for parsing non-utf8 chars (part 2) [2]
- Bump luatest to 1.0.1-33-g7dc5cb7 [3]

[1] tarantool/test-run@5d9630b
[2] tarantool/test-run@7acc532
[3] tarantool/test-run@dc2382c

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

(cherry picked from commit 0afc7e0b8a57678c589a2e9de6785d99f17e30eb)

When building an index in background, we create on_rollback triggers for
tuples inserted concurrently. The problem here is on_rollback trigger
has independent from `index` and `memtx_ddl_state` lifetime - it can be
called after the index was build (and `memtx_ddl_state` is destroyed)
and even after the index was altered. So, in order to avoid
use-after-free in on_rollback trigger, let's drop all on_rollback
triggers when the DDL is over. It's OK because all owners of triggers
are already prepared, hence, in WAL or replication queue (since we
build indexes in background only without MVCC so the transactions cannot
yield), so if they are rolled back, the same will happen to the DDL.

In order to delete on_rollback triggers, we should collect them into a
list in `memtx_ddl_state`. On the other hand, when the DML statement is
over (committed or rolled back), we should delete its trigger from the
list to prevent use-after-free. That's why the commit adds the on_commit
trigger to background build process.

Closes #10620

NO_DOC=bugfix

(cherry picked from commit d8d82dba4c884c3a7ad825bd3452d35627c7dbf4)

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

(cherry picked from commit 90d197ded13d49dfc405ff80bbd183b2e260dc56)

Also, adapt tests and helpers in accordance with the module interface.

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

(cherry picked from commit bd27df009c403e89c003d5b66763c0f0bbf08440)

Bump test-run to new version with the following improvements:

- ignore local lsn in wait_cluster_vclock [1]
- Bump luatest to 1.0.1-20-ga978383 [2]
- Bump luatest to 1.0.1-22-g39da6d2 [3]

[1] tarantool/test-run@f23b535
[2] tarantool/test-run@274e4f3
[3] tarantool/test-run@d04c595

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

(cherry picked from commit beba449a5f04e02fb77ca676663b1836e0490c3d)

Bump test-run to new version with the following improvements:

- Follow-up fix for parsing non-utf8 chars [1]

[1] tarantool/test-run@52d3e4f

NO_CHANGELOG=test
NO_TEST=test
NO_DOC=test

(cherry picked from commit e01c20edc31b65e020ac57e3f62a7427b6e27d53)

The test gh_10088 was committed in parallel with the luatest bump and
thus slipped from the post-bump tests fixup in commit cfd4bf46
("test: adapt tests to the new luatest version"). Fix it now.

Also tests gh_6539 and gh_7231 queried `box.cfg.log` wrongly, but this
didn't make them fail, they just stopped testing what they were supposed
to. Fix them as well

NO_CHANGELOG=test
NO_TEST=test
NO_DOC=test

(cherry picked from commit 2a18de391895d8ec7a39e3d3dcee659fe79f7bc9)

With the new version of Luatest you have to be careful with the server
log file. We used to get it very simply:

    box.cfg.log

Now it is more correct to use the following approach:

    rawget(_G, 'box_cfg_log_file') or box.cfg.log

Closes tarantool/test-run#439

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

(cherry picked from commit cfd4bf46)

Bump test-run to new version with the following improvements:

- luatest: fix ability to run a test several times [1]
- Enable luatest logging [2]
- tap13: fix parsing non-utf8 chars [3]

[1] tarantool/test-run@240cdea
[2] tarantool/test-run@b8b60b4
[3] tarantool/test-run@7290540

NO_DOC=test
NO_TEST=test
NO_CHANGELOG=test

(cherry picked from commit 59ba2131)

The commit bumps luafun to the new version with a bunch of bugfixes:
* Now `chain` works correctly with iterators without `param`.
* Now `drop_while` supports stateful iterators.
* The module is populated with missing `maximum_by` alias of `max_by`.
* Now `nth` and `length` work correctly with other luafun iterators.

Since our index iterators are stateful (can return different values
with the same `state` passed), the old `drop_while` implementation
didn't work well with them - it was skipping an extra element.
The bump resolves this issue.

Note that there are still methods that don't work correctly with
`index:pairs` - `cycle`, `head` and `is_null`.

Closes #6403

NO_DOC=bugfix

(cherry picked from commit ec758869f8364624efaff58bdd4ebc7c133ede0a)

GNU GCC compiler has UndefinedBehaviour sanitizer support since
4.9.0 [1], but it was unsupported in tarantool's build. The patch
fixes a build by GNU GCC with enabled UBSan.

1. https://gcc.gnu.org/gcc-4.9/changes.html

NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build

(cherry picked from commit 511e0f50e4b817d576ef4001611fba718ef1bdae)

The patch enable UBsan check signed-integer-overflow that was
disabled globally in commit 5115d9f3
("cmake: split UB sanitations into separate flags.") and disable
it for a several functions inline.

See also #10703
See also #10704
Closes #10228

NO_CHANGELOG=codehealth
NO_DOC=codehealth
NO_TEST=codehealth

(cherry picked from commit 60ba7fb4c0038d9d17387f7ce9755eb587ea1da4)

The following UBSan checks have been enabled back:

- vptr
- implicit-signed-integer-truncation
- implicit-integer-sign-change
- nullability-arg
- nullability-assign
- nullability-return
- returns-nonnull-attribute

These checks doesn't trigger errors anymore and no sense to keep
them disabled.

Part of #10228
Related to #10741
Related to #10740

NO_CHANGELOG=codehealth
NO_DOC=codehealth
NO_TEST=codehealth

(cherry picked from commit e65b63df7f5a8a628cd9a9bbc6a1bdecec8c9959)

The commit 366cb668 ("cmake: add option ENABLE_UB_SANITIZER")
added UndefinedBehaviour sanitizer support with the whitelist of
checks (all checks are disabled and a several checks are
enabled). The patch replaces the whitelist by blacklist (all
checks are enabled and a several checks are disabled).

Part of #10228
Related to #10742

NO_CHANGELOG=codehealth
NO_DOC=codehealth
NO_TEST=codehealth

(cherry picked from commit 2125a4304844669884bfa887657fd20f15504a5a)

Currently, we create `memtx_tx_snapshot_cleaner` for each index in read
view. However, we somewhy clarify all tuples against primary index in
all cleaners. As a result, secondary indexes work incorrectly in read
view when MVCC is enabled, we may even get a tuple with one key, but
a tuple with another key will be returned because it is clarified
against primary index and repsects its order - that's wrong because
all indexes have its own orders. Let's clarify tuples against given
index to fix this mistake.

Community Edition is not affected at all since it uses read view only
for making a snapshot - we use only primary indexes there.

Part of tarantool/tarantool-ee#939

NO_TEST=in EE
NO_CHANGELOG=in EE
NO_DOC=bugfix

(cherry picked from commit 835fadd)

I got compile error for release build on gcc 14.2.1 20240910 version.

```
In function ‘char* mp_store_double(char*, double)’,
    inlined from ‘char* mp_encode_double(char*, double)’ at /home/shiny/dev/tarantool-ee/tarantool/src/lib/msgpuck/msgpuck.h:2409:24,
    inlined from ‘uint32_t tuple_hash_field(uint32_t*, uint32_t*, const char**, field_type, coll*)’ at /home/shiny/dev/tarantool-ee/tarantool/src/box/tuple_hash.cc:317:46:
/home/shiny/dev/tarantool-ee/tarantool/src/lib/msgpuck/msgpuck.h:340:16: error: ‘value’ may be used uninitialized [-Werror=maybe-uninitialized]
  340 |         cast.d = val;
      |         ~~~~~~~^~~~~
/home/shiny/dev/tarantool-ee/tarantool/src/box/tuple_hash.cc: In function ‘uint32_t tuple_hash_field(uint32_t*, uint32_t*, const char**, field_type, coll*)’:
/home/shiny/dev/tarantool-ee/tarantool/src/box/tuple_hash.cc:311:24: note: ‘value’ was declared here
  311 |                 double value;
      |
```

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

(cherry picked from commit 1129c758d0e3bd86eec89e5229eac3f99155d8ac)

* Fix typo.
* OSX/iOS: Always generate 64 bit non-FAT Mach-O object files.
* test: don't run JIT-based LuaJIT tests without JIT
* test: actualize <LuaJIT-tests/README.md>
* test: enable <misc/alias_alloc.lua> LuaJIT test
* test: refactor <alias_alloc.lua> LuaJIT test
* test: refactor <lang/coroutine.lua> LuaJIT test
* test: remove <misc/coro_yield.lua> LuaJIT test
* test: enable <misc/debug_gc.lua> LuaJIT test
* test: enable <misc/dualnum.lua> LuaJIT test
* test: refactor <lang/dualnum.lua> LuaJIT test
* test: remove <misc/fori_coerce.lua> LuaJIT test
* test: remove <misc/fori_dir.lua> LuaJIT test
* test: remove <misc/gc_rechain.lua> LuaJIT test
* test: enable <misc/gc_trace.lua> LuaJIT test
* test: refactor <trace/gc.lua> LuaJIT test
* test: enable <misc/gcstep.lua> LuaJIT test
* test: enable <misc/hook_active.lua> LuaJIT test
* test: enable <misc/hook_line.lua> LuaJIT test
* test: enable <misc/hook_norecord.lua> LuaJIT test
* test: enable <misc/hook_record.lua> LuaJIT test
* test: enable <misc/hook_top.lua> LuaJIT test
* test: enable <misc/jit_flush.lua> LuaJIT test
* test: remove <misc/loop_unroll.lua> LuaJIT test
* test: enable <misc/parse_comp.lua> LuaJIT test
* test: enable <misc/parse_esc.lua> LuaJIT test
* test: enable <misc/parse_misc.lua> LuaJIT test
* test: enable <misc/phi_conv.lua> LuaJIT test
* test: refactor <trace/phi/conv.lua> LuaJIT test
* test: enable <misc/recurse_deep.lua> LuaJIT test
* test: remove <misc/recurse_tail.lua> LuaJIT test
* test: enable <misc/stack_gc.lua> LuaJIT test
* test: refactor <lang/gc_stack.lua> LuaJIT test
* test: enable <misc/stack_purge.lua> LuaJIT test
* test: refactor <trace/stack_purge.lua> LuaJIT test
* test: enable <misc/stackov.lua> LuaJIT test
* test: enable <misc/stackovc.lua> LuaJIT test
* test: enable <misc/tcall_base.lua> LuaJIT test
* test: refactor <trace/tcall_base.lua> LuaJIT test
* test: enable <misc/tcall_loop.lua> LuaJIT test
* test: enable <misc/tonumber_scan.lua> LuaJIT test
* test: remove <misc/uclo.lua> LuaJIT test
* test: enable <misc/unordered_jit.lua> LuaJIT test
* test: enable <misc/wbarrier.lua> LuaJIT test
* test: enable <misc/wbarrier_jit.lua> LuaJIT test
* test: enable <misc/wbarrier_obar.lua> LuaJIT test
* test: update <LuaJIT-tests/README.md>
* test: off JIT for routines in <lang/stackov.lua>
* Limit number of string format elements to compile.
* Clear stack after print_jit_status() in CLI.
* FFI: Workaround for platform dlerror() returning NULL.
* test: move profilers tests to subdirectory
* test: rename <arm64-ccall-fp-convention.test.lua>
* cmake: introduce AppendTestEnvVar macro
* test: shrink LUA_PATH environment variable
* test: shrink LUA_CPATH and {DY}LD_LIBRARY_PATH
* test: skip flaky tests with enabled table bump
* test: set LD_PRELOAD only when necessary
* test: fix misclib-getmetrics-lapi.test.lua
* FFI: Fix __tostring metamethod access to enum cdata value.
* Fix limit check in narrow_conv_backprop().
* FFI: Drop finalizer table rehash after GC cycle.
* Drop unused function wrapper.
* FFI: Fix various issues in recff_cdata_arith.
* Add missing coercion when recording select(string, ...)
* Fix stack allocation after on-trace stack check.
* Restore state when recording __concat metamethod throws an error.
* Fix bit op coercion in DUALNUM builds.
* FFI: Fix 64 bit shift fold rules.
* Limit CSE for IR_CARG to fix loop optimizations.

Closes #10290
Closes #10199
Closes #9898
Part of #9398

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump