Persist and expose sharding function for external / cluster wide access

[Totktonada]

When we'll implement #5496, we'll able to configure vshard on all nodes. However it is not enough to read and write actual data: we should also know a sharding function (key -> bucket_id transformation). Modules like tarantool/crud should use this information to access data.

Maybe a text of a Lua function and a list of used modules (like digest) will be enough.

[Totktonada]

Maybe it should be part of the schema in the tarantool/ddl module. If so, it'll fall into the following subtasks:

• Learn tarantool/ddl to store the schema in the configuration provider.
• Add the sharding function information into the schema.

[artur-barsegyan]

Maybe it should be part of the schema in the tarantool/ddl module. If so, it'll fall into the following subtasks:

• Add the sharding function information into the schema.

From the experience of communicating with clients, basically you need to shard the data somehow. In the current version, tarantool/ddl already supports sharding by a set of fields, so there is no need to do this.

[Mons]

From the experience of communicating with clients, basically you need to shard the data somehow. In the current version, tarantool/ddl already supports sharding by a set of fields, so there is no need to do this.

Storage of custom user function is a required feature.

[Totktonada]

@Mons,

Storage of custom user function is a required feature.

Do you mean applying a custom function on tuple's fields declared by given sharding_key (a set of tuple's fields suitable for deducing a bucket_id) or something more general?