* Followup fix for embedded bytecode loader. * Fix embedded bytecode loader. Part of #9145 NO_DOC=LuaJIT submodule bump NO_TEST=LuaJIT submodule bump

Bump test-run to new version with the following improvements: - Bump luatest to 1.0.0-5-gf31fe34 [1] - get_iproto_port: remove duplicates [2] - requirements: bump gevent to 22.10.2 [3] - Fix decoding error when reading server's log file [4] [1] tarantool/test-run@bfcc9e8 [2] tarantool/test-run@da98d7f [3] tarantool/test-run@bc1c473 [4] tarantool/test-run@434cbec NO_DOC=test NO_TEST=test NO_CHANGELOG=test

Switch the legacy `box.iproto.override()' interface to the newly introduced event triggers. This change is mostly not user-visible, except: - Now it can be called before `box.cfg{}'; - Now request type can be set as a string; - Some changes in error messages; - The "overriding does not support ... request type" error is logged, rather than raised; - The internal trigger is visible via the `trigger' module. If some request type is overridden by both interfaces (legacy `box.iproto.override()' and new `trigger.set()'), the order of invocation of the handlers is unspecified. Closes #8138 NO_DOC=internal

This patch allows to override IPROTO request handlers by setting triggers on the corresponding events after the initial `box.cfg{}' call. Part of #8138 @TarantoolBot document Title: Document iproto override using event triggers Product: Tarantool Since: 3.1 Root document: New page - https://www.tarantool.io/en/doc/latest/reference/reference_lua/trigger/ Since Tarantool 3.1 there are 2 ways to override iproto request handlers: 1. Using `box.iproto.override()`, introduced in Tarantool 2.11: https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_iproto/override/ 2. Using universal trigger registry: tarantool/doc#3988 To override an iproto request handler for the given request type, one can set a trigger (or multiple triggers) on the corresponding event. There are 2 types of iproto-overriding events: 1. set by request type id, e.g.: - box.iproto.override[1] - box.iproto.override[-1] 2. set by request type name (the name must be in the lowercase), e.g.: - box.iproto.override.select - box.iproto.override.unknown Override-by-id allows to set a handler for a particular request type, that is not known by the given version of Tarantool. This is not possible with override-by-name, where a type name must be known by Tarantool. Also there are a special type name "unknown" and a type id box.iproto.type.UNKNOWN (== -1) that allow to set a single handler for all unknown request types. Multiple triggers can be associated with a single event. The triggers are called in reverse order of their installation, however triggers set by id are called before triggers set by name. If a trigger returns `false`, the next trigger in the list is called, or a system handler if there are no more triggers. If a trigger returns `true`, no more triggers or system handlers are called. If some request type is overridden by both interfaces (legacy `box.iproto.override()' and new `trigger.set()'), the order of invocation of those handlers is unspecified. Co-authored-by: Andrey Saranchin <Andrey22102001@gmail.com>

This patch allows to override IPROTO request handlers by setting triggers on the corresponding events before the initial `box.cfg{}' call. For triggers that are set after the first `box.cfg{}', see next commit. There are 2 types of iproto-overriding events: 1. set by request type id, e.g.: - box.iproto.override[1] - box.iproto.override[-1] 2. set by request type name (the name must be in the lowercase), e.g.: - box.iproto.override.select - box.iproto.override.unknown Override-by-id allows to set a handler for a particular request type, that is not known by the given version of Tarantool. This is not possible with override-by-name, where a type name must be known by Tarantool. Also there are a special type name "unknown" and a type id box.iproto.type.UNKNOWN (== -1) that allow to set a single handler for all unknown request types. Multiple triggers can be associated with a single event. The triggers are called in reverse order of their installation, however triggers set by id are called before triggers set by name. If a trigger returns `false`, the next trigger in the list is called, or a system handler if there are no more triggers. If a trigger returns `true`, no more triggers or system handlers are called. Part of #8138 NO_DOC=see next commit NO_CHANGELOG=see next commit Co-authored-by: Andrey Saranchin <Andrey22102001@gmail.com>

So far only one type of a handler can be set for a particular request type, but the following commit will bring two more handlers. This patch prepares `struct iproto_req_handler` for this extension to simplify next commits. Part of #8138 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring

This patch adds `iproto_key_translation' to the MsgPack decoding context, that is used to decode xrow header and body in the space recovery triggers. NO_DOC=Minor improvement NO_CHANGELOG=Minor improvement

It works like func_adapter_push_msgpack, but with an additional MsgPack decoding context. The context is required to support translation of first-level `MP_MAP` keys. Needed for #8138 NO_DOC=internal NO_CHANGELOG=internal

Since we are going to move iproto override mechanism to the trigger registry, we need to allow to set core triggers to on change event because we need to notify iproto threads when a handler is overridden. Let's add a new method that accepts a core trigger and sets it to an internal trigger list. Needed for #8138 NO_DOC=internal NO_CHANGELOG=internal

Test box-luatest/iproto_request_handlers_overriding_test.lua has two test cases with the same name. That is why a test case that was declared first is replaced by the second one and that's why it is not launched. The commit renames one of the cases. NO_CHANGELOG=test NO_DOC=test