This PR fixes #4750 by introducing document compression to Meilisearch.

I had to use thezstdlibrary directly instead of thelz4_flexbecause the latter doesn't provide an option to specify the compression level.According to the documentation,I used:

• A compression level of 19,
• A dictionary size of 64000 bytes,
• The first 10k documents in the LMDB database as the sample to generate the dictionary,
• The dictionary is generated if there is no dictionary yet and we have reached 10k documents,
• The dictionary is deleted when all the documents are deleted (index clear or by hand).

Note that the benchmarks only represent the first couple hours of real usage: When the user uploads some documents and settings, the number of documents reaches 10k+. This PR will compress the documents when there are 10k+ with a dictionary generated from them and thenneverchanges the dictionary (but if no documents are left).

The first results show between 2x and 3x compression of the documents database (from a 25GiB to a 16GiB data.ms and an average document size going from 305B to 126B). Still, we can see performance regression due to the compression done on a single thread (👇).

To do

• Resolve merge conflicts by rebasing on main
• Make sure the tests are passing
• Measure performance impact withAdd search benchmarks#4762
• Simplify the usage of document decoding
• Specify a const for document sample size, compression level, and dictionary size
• Compress the documents in parallel instead of in the write loop
• See if we can use theexperimentalzstdfeature toavoid copying 64k bytes in memory.