There was a problem: chunked request to etcd via TLS using builtin http client returns nothing. The problem reproduced quite often by a test `integration.general.tls` in etcd-client Lua module. The patch updates curl submodule to a version based on 8.5.0 release with applied patch [1]. The patch also removes workaround made in commit aa58c21206f0 ("httpc: use http 1.1 by default"). 1. https://github.com/curl/curl/pull/12740 Fixes #9547 NO_TEST=etcd-client tests NO_DOC=bugfix

This update pulls the following commit: * Introduce mp_read_int8 and mp_read_int16 functions Needed for tarantool/tarantool-ee#627 NO_DOC=internal NO_CHANGELOG=internal NO_TEST=submodule update

- First endswith returns boolean so fix where it compared with nil. Due to the invalid comparison we actually don't check for prompt in nested case. - Add trailing space to prompt in this test case. - Reset readline configuration in this test case. NO_CHANGELOG=test fix NO_DOC=test fix

In contrast to space_cache_find(), space_by_id() doesn't cache the last looked up space to speed up following lookups. This is confusing, because one would expect the only difference between space_cache_find() and space_by_id() functions to be that the former sets diag while the latter doesn't. Let's move the prev_space cache to space_by_id() to fix this issue. To achieve that we need to make space_by_id() inline, which is tricky because it's called via FFI. We work around that by defining a macro space_by_id() which expands to space_by_id_fast() while still keeping the space_by_id() symbol for FFI. Last but not least, we make the last cached space global (currently it's instantiated once per each space_cache_find() call site). This is a good thing because we often call space_by_id() a few times while processing the same DML request (e.g. in memtx mvcc). NO_DOC=no user-visible behavior changes NO_TEST=no user-visible behavior changes NO_CHANGELOG=no user-visible behavior changes

- Drop testing for FreeBSD 12 since FreeBSD 14 is available - Add testing for FreeBSD 14 NO_DOC=ci NO_TEST=ci NO_CHANGELOG=ci

See the docbot request for details. Closes #9548 @TarantoolBot document Title: Document fixed-size numeric field types Product: Tarantool Since: 3.1 Root document: https://www.tarantool.io/en/doc/latest/concepts/data_model/value_store/#field-type-details ### Fixed-size field types Tarantool supports the following fixed-size numeric field types: * `uint8`: integer in range [0 .. 255] * `int8`: integer in range [-128 .. 127] * `uint16`: integer in range [0 .. 65,535] * `int16`: integer in range [-32,768 .. 32,767] * `uint32`: integer in range [0 .. 4,294,967,295] * `int32`: integer in range [-2,147,483,648 .. 2,147,483,647] * `uint64`: integer in range [0 .. 18,446,744,073,709,551,615] * `int64`: integer in range [-9,223,372,036,854,775,808 .. 9,223,372,036,854,775,807] * `float32`: 32-bit floating point number * `float64`: 64-bit floating point number These types don't affect how data is stored in Tarantool's memtx or vinyl engines but they enforce the limits when a tuple is inserted or updated.

All the information needed by this function is stored in `field_mp_type[]' and `field_ext_type[]'. Get rid of redundant `field_type_compatibility[]', which is hard to extend and which can introduce additional bugs. NO_DOC=refactoring NO_CHANGELOG=refactoring

commit 51af059c10ff ("box: compare and hash msgpack value of double key field as double") changed `field_mp_type[FIELD_TYPE_DOUBLE]', but the corresponding column of `field_type_compatibility[]' wasn't updated. Now a field of type DOUBLE can store MP_UINT and MP_INT, i.e. it can store any value from fields of type UNSIGNED, NUMBER, INTEGER. In fact, FIELD_TYPE_DOUBLE is now an alias for FIELD_TYPE_NUMBER. It's hard to create a test, because e.g. during CheckSpaceFormat even if field_type1_contains_type2() erroneously returns false, then each tuple is correctly validated anyway. So this patch actually fixes performance issue. NO_TEST=see above NO_DOC=minor fix NO_CHANGELOG=minor fix

Not used since we moved result processing to the memtx engine. NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring

Initially, we tried to upgrade tuples in the engine-independent code, for which purpose we added the result processor, see commit 21e2def9dec9 ("box: introduce result processor"). It turned out, we still need to do some upgrade-related work in the memtx engine, see commit f7a520ef13db ("box: don't apply space upgrade func to DML result except for DELETE") and commit 921a07177521 ("memtx: add stubs to keep track of upgraded read view tuples"). Since the memtx engine is the only engine that currently supports space upgrade, let's simplify the code by moving space upgrade handling completely in the memtx engine. This is easy to do because we already have memtx_prepare_result_tuple() helper that decompresses tuples before returning them to the user, which seems to be the perfect place for handling upgrade. NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring