This change implements support for Zstd-based compression in LevelDB. Building
up from the Snappy compression (which has been supported since inception), this
change adds Zstd as an alternate compression algorithm.

We are implementing this to provide alternative options for users who might
have different performance and efficiency requirements. For instance, the
Zstandard website (https://facebook.github.io/zstd/) claims that the Zstd
algorithm can achieve around 30% higher compression ratios than Snappy, with
relatively smaller (~10%) slowdowns in de/compression speeds.

Benchmarking results:

$ blaze-bin/third_party/leveldb/db_bench
LevelDB:    version 1.23
Date:       Thu Feb  2 18:50:06 2023
CPU:        56 * Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz
CPUCache:   35840 KB
Keys:       16 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    1000000
RawSize:    110.6 MB (estimated)
FileSize:   62.9 MB (estimated)
------------------------------------------------
fillseq      :       2.613 micros/op;   42.3 MB/s
fillsync     :    3924.432 micros/op;    0.0 MB/s (1000 ops)
fillrandom   :       3.609 micros/op;   30.7 MB/s
overwrite    :       4.508 micros/op;   24.5 MB/s
readrandom   :       6.136 micros/op; (864322 of 1000000 found)
readrandom   :       5.446 micros/op; (864083 of 1000000 found)
readseq      :       0.180 micros/op;  613.3 MB/s
readreverse  :       0.321 micros/op;  344.7 MB/s
compact      :  827043.000 micros/op;
readrandom   :       4.603 micros/op; (864105 of 1000000 found)
readseq      :       0.169 micros/op;  656.3 MB/s
readreverse  :       0.315 micros/op;  350.8 MB/s
fill100K     :     854.009 micros/op;  111.7 MB/s (1000 ops)
crc32c       :       1.227 micros/op; 3184.0 MB/s (4K per op)
snappycomp   :       3.610 micros/op; 1081.9 MB/s (output: 55.2%)
snappyuncomp :       0.691 micros/op; 5656.3 MB/s
zstdcomp     :      15.731 micros/op;  248.3 MB/s (output: 44.1%)
zstduncomp   :       4.218 micros/op;  926.2 MB/s
PiperOrigin-RevId: 509957778

Fixes an unused variable warning.

See https://github.com/google/leveldb/issues/1081

PiperOrigin-RevId: 499519182

PiperOrigin-RevId: 461725664

PiperOrigin-RevId: 461722304

PiperOrigin-RevId: 461695246

PiperOrigin-RevId: 461612590

This replaces a usage of fprintf to stderr

PiperOrigin-RevId: 454620969

PiperOrigin-RevId: 447466466

Structs with user-declared constructors are no longer considered
aggregates.  Just remove the constructor declaration where applicable.

Bug: chromium:1284275

PiperOrigin-RevId: 422409116

* Align CONTRIBUTING.md with the google/new-project template.
* Explain the support story for the CMake config.

PiperOrigin-RevId: 421120645

PiperOrigin-RevId: 420787858

PiperOrigin-RevId: 420783873

PiperOrigin-RevId: 420783487

PiperOrigin-RevId: 420782536

PiperOrigin-RevId: 420781374

PiperOrigin-RevId: 420781095

PiperOrigin-RevId: 420778907

PiperOrigin-RevId: 420662938

PiperOrigin-RevId: 420662891

PiperOrigin-RevId: 420645727

PiperOrigin-RevId: 420645080

PiperOrigin-RevId: 420644954

PiperOrigin-RevId: 420541137

PiperOrigin-RevId: 420534594

PiperOrigin-RevId: 420533763

PiperOrigin-RevId: 420532625

PiperOrigin-RevId: 420517390

PiperOrigin-RevId: 420504266

PiperOrigin-RevId: 420403341

PiperOrigin-RevId: 420399272

This gives some flexibility to embedders.

Currently, embedders have to build a binary for each test file.

After this CL, embedders can still choose to have a binary for each test
file, by linking each test file with a googletest target that includes
main() (usually "gtest_main"). Embedders can also choose to build a
single binary for almost all test files, and link with a googletest
target that includes main(). The latter is more convenient for projects
that have very few test binaries, like Chromium.

PiperOrigin-RevId: 419470798

The benchmark in db/db_test.cc is extracted to its own file,
benchmarks/db_bench_log.cc.

PiperOrigin-RevId: 418713499

PiperOrigin-RevId: 417853172

PiperOrigin-RevId: 412997201

PiperOrigin-RevId: 412965575

I recently encountered a problem with this because Windows doesn't allow
files to be deleted when there's open handles to them.

Other files opened by leveldb are not affected because by and large they
are using CreateFileA, which does not allow inheritance when
lpSecurityAttributes is null (ref:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea)

However, fopen() _does_ allow inheritance, and it needs to be expressly
disabled.
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-160

PiperOrigin-RevId: 395824737

Fix typo of comment of FindLargestKey function

PiperOrigin-RevId: 394542401