Replace all usage of ziplist with listpack for t_hash

[sundb]

Part one of implementing #8702 (taking hashes first before other types)

Description of the feature

1. Change ziplist encoded hash objects to listpack encoding.
2. Convert existing ziplists on RDB loading time. an O(n) operation.

Rdb format changes

1. Add RDB_TYPE_HASH_LISTPACK rdb type.
2. Bump RDB_VERSION to 10

Interface changes

1. New hash-max-listpack-entries config is an alias for hash-max-ziplist-entries (same with hash-max-listpack-value)
2. OBJECT ENCODING will return listpack instead of ziplist

Listpack improvements:

1. Support direct insert, replace integer element (rather than convert back and forth from string)
2. Add more listpack capabilities to match the ziplist ones (like lpFind, lpRandomPairs and such)
3. Optimize element length fetching, avoid multiple calculations
4. Use inline to avoid function call overhead.

Tests

1. Add a new test to the RDB load time conversion
2. Adding the listpack unit tests. (based on the one in ziplist.c)
3. Add a few "corrupt payload: fuzzer findings" tests, and slightly modify existing ones.

[oranagra]

@sundb thank you for that effort.

i've added a few comments inside the code, but here are some general ones:

1. i don't like the term "list container". in "ziplist" and "listpack", we mention it is zipped, or packed, i.e. encoded. this container can be more easily mistaken to be something related to list data type rather than an encoding type.
   maybe a term like "encoded list" or "packed list" (i.e. something that is generic, and both ziplist and listpack comply to, i.e. both ziplist and listpack are encoded and packed).
2. currently we only create new hashes with listpack, and when modifying an existing hashes we'll always keep them as ziplists.
   we need to see if we can come up with a plan to gradually convert them.
   i.e. i don't want an O(N) operation at load time or any other time, but eventually i want them all gone.
3. we have a problem with testing. the majority of the tests work by creating a new db from scratch, so the ziplist code is now mostly unreachable.
   maybe we need some DEBUG sub-command that will tell redis to default to creating ziplists, and then run the entire testsuite in that mode (in the daily CI)
   i'm specifically worried about the corrupt-dump-fuzzer test. we either need to save an old rdb file in the assets folder, or let it run twice with that DEBUG tweak i suggested.

[oranagra]

One more thing, we need an option to convert the encoding at rdb loading time.
either when doing full sanitization, since in that case we already do O(N) operation anyway, but also maybe some people will want to do that conversion at upgrade time (slave will take longer to go online), maybe we'll even make it the default one day.

i think it would also be a good idea to benchmark such a conversion, and get a feeling of how much longer it takes to load an rdb file if we do a conversion during loading vs one that just loads the ziplists as they are. can you try doing such a benchmark?

[sundb]

1. i don't like the term "list container". in "ziplist" and "listpack", we mention it is zipped, or packed, i.e. encoded. this container can be more easily mistaken to be something related to list data type rather than an encoding type.
   maybe a term like "encoded list" or "packed list" (i.e. something that is generic, and both ziplist and listpack comply to, i.e. both ziplist and listpack are encoded and packed).

I also do not like "list container", it is too difficult to come up with a good name.

2. currently we only create new hashes with listpack, and when modifying an existing hashes we'll always keep them as ziplists.
   we need to see if we can come up with a plan to gradually convert them.
   i.e. i don't want an O(N) operation at load time or any other time, but eventually i want them all gone.

Maybe we can convert ziplist to listpack when call hashTypeInitIterator.

3. we have a problem with testing. the majority of the tests work by creating a new db from scratch, so the ziplist code is now mostly unreachable.
   maybe we need some DEBUG sub-command that will tell redis to default to creating ziplists, and then run the entire testsuite in that mode (in the daily CI)
   i'm specifically worried about the corrupt-dump-fuzzer test. we either need to save an old rdb file in the assets folder, or let it run twice with that DEBUG tweak i suggested.

I have write corrupt-dump-fuzzer test in #8761, I will complete these tests.

[sundb]

@oranagra I tested the speed of rdb loading, before(keep ziplsit) and after(convert ziplist) using the same dump.rdb, creating 100000 keys per test and filling value with random strings.
It looks like the speed becomes 3 times of the original.

entries num of one ziplist	max value size	rdb loading time without convert	rdb loading time with convert
256	64bytes	6.888s	18.078s
256	32bytes	6.849s	17.869s
256	16bytes	6.991s	18.0842s
128	64bytes	3.553s	8.983s
128	32bytes	3.521s	9.0222s
128	16bytes	3.558s	8.982s

[dev-lemontree]

@sundb @oranagra I have a question. It can still support old RDB Version?
If we try to migrate Redis 6 to Redis 7 with replication, Maybe Redis 6 creates RDB with old version(using ziplist), Does Redis 7 load it(Redis 6 RDB)?
It is very common pattern to upgrade redis server.

[sundb]

@dev-lemontree Indeed, It is backward compatible.