Alternate Compression Implementations

[cody-littley]

Gzip compression in the standard java libraries is too slow for reconnect. Consider alternate implementations that are faster.

[kfrz]

https://engineering.fb.com/2016/08/31/core-infra/smaller-and-faster-data-compression-with-zstandard/

https://datatracker.ietf.org/doc/html/rfc8878

https://swiftpackageindex.com/facebook/zstd

https://github.com/facebook/zstd/blob/dev/Package.swift

https://swiftpackageindex.com/facebook/zstd

https://github.com/aperedera/SwiftZSTD

https://facebook.github.io/zstd/#other-languages

https://github.com/Cyan4973/FiniteStateEntropy

Without personal insight into the finer details of the existing benchmarks as it compares apples-to-apples, this still looks compelling to at least consider. When I searched I was pleased to find concurrent thinking!

I can't into Java-ing, but I did read about zstd this weekend they're puttin' up Pied Piper numbers, Weissman score in the fives:

---

The following is sourced from the README

Benchmarks

For reference, several fast compression algorithms were tested and compared
on a desktop running Ubuntu 20.04 (Linux 5.11.0-41-generic),
with a Core i7-9700K CPU @ 4.9GHz,
using lzbench, an open-source in-memory benchmark by @inikep
compiled with gcc 9.3.0,
on the Silesia compression corpus.

Compressor name	Ratio	Compression	Decompress.
zstd 1.5.1 -1	2.887	530 MB/s	1700 MB/s
zlib 1.2.11 -1	2.743	95 MB/s	400 MB/s
brotli 1.0.9 -0	2.702	395 MB/s	450 MB/s
zstd 1.5.1 --fast=1	2.437	600 MB/s	2150 MB/s
zstd 1.5.1 --fast=3	2.239	670 MB/s	2250 MB/s
quicklz 1.5.0 -1	2.238	540 MB/s	760 MB/s
zstd 1.5.1 --fast=4	2.148	710 MB/s	2300 MB/s
lzo1x 2.10 -1	2.106	660 MB/s	845 MB/s
lz4 1.9.3	2.101	740 MB/s	4500 MB/s
lzf 3.6 -1	2.077	410 MB/s	830 MB/s
snappy 1.1.9	2.073	550 MB/s	1750 MB/s

The negative compression levels, specified with --fast=#,
offer faster compression and decompression speed
at the cost of compression ratio (compared to level 1).

Zstd can also offer stronger compression ratios at the cost of compression speed.
Speed vs Compression trade-off is configurable by small increments.
Decompression speed is preserved and remains roughly the same at all settings,
a property shared by most LZ compression algorithms, such as zlib or lzma.