* 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>