NO_CHANGELOG=internal NO_DOC=internal NO_TEST=internal

"Resource temporarily unavailable" NO_CHANGELOG=internal NO_DOC=internal NO_TEST=internal

Before this patch struct tuple had two boolean bit fields: is_dirty and has_uploaded_refs. It is worth mentioning that sizeof(boolean) is implementation depended. However, in code it is assumed to be 1 byte (there's static assertion restricting the whole struct tuple size by 10 bytes). So strictly speaking it may lead to the compilation error on some non-conventional system. Secondly, bit fields anyway consume at least one size of type (i.e. there's no space benefits in using two uint8_t bit fields - they anyway occupy 1 byte in total). There are several known pitfalls concerning bit fields: - Bit field's memory layout is implementation dependent; - sizeof() can't be applied to such members; - Complier may raise unexpected side effects (https://lwn.net/Articles/478657/). Finally, in our code base as a rule we use explicit masks: txn flags, vy stmt flags, sql flags, fiber flags. So, let's replace bit fields in struct tuple with single member called `flags` and several enum values corresponding to masks (to be more precise - bit positions in tuple flags). NO_DOC=<Refactoring> NO_CHANGELOG=<Refactoring> NO_TEST=<Refactoring>

We did not retain correctly `hour` attribute if modified via `:set` method attributes `min`, `sec` or `nsec`. ``` tarantool> a = dt.parse '2022-05-05T00:00:00' tarantool> a:set{min = 0, sec = 0, nsec = 0} -- - 2022-05-05T12:00:00Z ... ``` Closes #7298 NO_DOC=bugfix

If vy_point_lookup called by vy_sauash_process yields (doing disk read), a dump may be triggered bumping the L0 generation counter, in which case we would insert a statement to a sealed vy_mem, as explained in #5080. Let's check the generation counter and rotate the active vy_mem if necessary after vy_point_lookup to avoid that. Closes #5080 NO_DOC=bug fix NO_TEST=complicated, need stress/perf test to catch bugs like this

We often call vy_lsm_rotate_mem_if_required if its generation or schema version is older than the current one. Let's add a helper function for that. Needed for #5080 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring

The optimization is mostly useless, because it only works if there's no data on disk. As explained in #5080, it contains a potential bug: if L0 dump is triggered between 'prepare' and 'commit', it will insert a statement to a sealed vy_mem. Let's drop it. Part of #5080 NO_DOC=bug fix NO_CHANGELOG=later

gh_6634_different_log_on_tuple_new_and_free_test.lua verifies that proper debug message gets into logs for tuple_new() and tuple_delete(): occasionally tuple_delete() printed wrong tuple address. However, still there are two debug logs: one in tuple_delete() and another one in memtx_tuple_delete(). So to avoid any possible confusions let's fix regular expression to find proper log so that now it definitely finds memtx_tuple_delete(). NO_CHANGELOG=<Test fix> NO_DOC=<Test fix>

Net.box triggers (on_connect, on_schema_reload) are executed by the net.box connection worker fiber so a request issued by a trigger callback can't be processed until the trigger returns execution to the net.box fiber. Currently, an attempt to issue a synchronous request from a net.box trigger leads to a silent hang of the connection, which is confusing. Let's instead raise an error until #7291 is implemented. We need to add the check to three places in the code: 1. luaT_netbox_wait_result for future:wait_result() 2. luaT_netbox_iterator_next for future:pairs() 3. conn._request for all synchronous requests. (We can't add the check to luaT_netbox_transport_perform_request, because conn._request may also call conn.wait_state, which would hang if called from on_connect or on_schema_reload trigger.) We also add an assertion to netbox_request_wait to ensure that we never wait for a request completion in the net.box worker fiber. Closes #5358 @TarantoolBot document Title: Synchronous requests are not allowed in net.box triggers An attempt to issue a synchronous request (e.g. `call`) from a net.box trigger (`on_connect`, `on_schema_reload`) now raises an error: "Synchronous requests are not allowed in net.box trigger" (Before https://github.com/tarantool/tarantool/issues/5358 was fixed, it silently hung.) Invoking an asynchronous request (see `is_async` option) is allowed, but the request will not be processed until the trigger returns and an attempt to wait for the request completion with `future:pairs()` or `future:wait_result()` will raise the same error.

`wal_write` has been adapted to spurious wakeups, so this protection is no longer needed (see 4bf52367a745bd4d33d4727e2a8c574f2da9094d). Part of #7166 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring