Possible schema hashing false mismatch due to unstable msgpack map serialization

[GRISHNOV]

While working on the task, it was discovered that msgpack does not guarantee the order of elements when serializing map.

Input for example:

{
  indexes = { {
      parts = { {
          exclude_null = false,
          fieldno = 2
        } }
    },
    [0] = {
      parts = { {
          exclude_null = false,
          fieldno = 1
        } }
    }
  }
}

Serializing output on different hosts:

��indexes���parts���exclude_null§fieldno��parts���exclude_null§fieldno

��indexes���parts���fieldno�exclude_null���parts���fieldno�exclude_null�

It can be seen that the fields exclude_null and fieldno have different order on different hosts.
Since this is used to get the hash and determine if the schema needs to be reloaded, we may get a false schema mismatch problem:

crud/crud/common/schema.lua

Line 139 in 781ef16

return digest.murmur(msgpack.encode(space_info))

It should also be noted that a similar calculation approach is used in other places:

crud/crud/common/sharding/utils.lua

Line 31 in 781ef16

return digest.murmur(msgpack.encode(val))