api: support IPROTO_FEATURE_SPACE_AND_INDEX_NAMES

[DerekBum]

Support IPROTO_FEATURE_SPACE_AND_INDEX_NAMES for Tarantool version >= 3.0.0-alpha1. It allows to use space and index names in requests instead of their IDs.

ResolveSpaceIndex function for SchemaResolver interface split into two: ResolveSpace and ResolveIndex. NamesUseSupported function added into the interface to get information if usage of space and index names is supported.

Schema structure no longer implements SchemaResolver interface.

Update Tarantool EE version 1.10.11 to 1.10.15, 2.10.0 to 2.10.8 and 2.11.0 to 2.11.1. This was done because of the one flacking test: https://github.com/tarantool/go-tarantool/actions/runs/6805504621/job/18505152412

I didn't forget about (remove if it is not applicable):

• Tests (see documentation for a testing package)
• Changelog (see documentation for changelog format)
• Documentation (see documentation for documentation style guide)

Closes #338

[DerekBum]

Right now uint32 is used as a type for ids of spaces and indexes (and other iproto constants). Maybe it would be better to create out own type IprotoType uint32 and use it instead? It will help with the code readability and will also make changing types easier (in case if iproto will start accepting something other than uint32). Maybe create a type only for ids of spaces and indexes.
But it also will complicate the code in some places (as example, to decode the id, we could not use DecodeUint32. We would need to first get the result of DecodeUint32, check if err is nil, and then convert it to IprotoType).

[oleg-jukovec]

Right now uint32 is used as a type for ids of spaces and indexes (and other iproto constants). Maybe it would be better to create out own type IprotoType uint32 and use it instead?

The idea do not use a big 9-bytes values. I think we could choose a largest possible type (int64 or uint64 - we need recheck it) and use EncodeInt()/EncodeUint() to encode the values.

[oleg-jukovec]

It seems to me that we need to reconsider the tests with different resolver options. Now it is not entirely clear what is being tested and why.

As example, we need to test:

1. If NamesUseSupported() == true + space == "string" -> ResolveSpace() is not called by requests Body().
2. If NamesUseSupported() == true + space == "string" -> ResolveIndex() is not called by requests Body().
3. If NamesUseSupported() == false + space == "string" -> ResolveSpace() is called by requests Body() to resolve space id.
4. If NamesUseSupported() == true + space == "string" -> ResolveIndex() is called by requests Body() to resolve index id.

It should be enough. Other tests should test what the actually test (default values, setters, invalid spaces and etc), not the behavior of resolving.

[oleg-jukovec]

Thank you for the patch. Just a few mirror notes to fix:

[DifferentialOrange]

Sorry, I had forgot to click "Finish your review"