Replace miniz.c with a pure-Rust implementation

[bstrie]

As of today, it looks like the only two in-tree C dependencies are libbacktrace and miniz. Unlike libbacktrace, the existence of pure-Rust (de)compression libs sounds broadly useful and feasible to implement. Determine which functions in miniz we actually need and explore whether or not any crates in our library ecosystem can serve as a suitable replacement.

[kennytm]

miniz is only used in the flate crate, which probably could be replaced by an external crate (flate2? deflate?) as a whole. Compression speed seems to be a primary concern.

/// Compress a buffer without writing any sort of header on the output. Fast
/// compression is used because it is almost twice as fast as default
/// compression and the compression ratio is only marginally worse.
pub fn deflate_bytes(bytes: &[u8]) -> Bytes;

/// Decompress a buffer without parsing any sort of header on the input.
pub fn inflate_bytes(bytes: &[u8]) -> Result<Bytes, Error>;

[est31]

There is also compiler-rt, but its being replaced by a pure rust implementation.

[BurntSushi]

Do you need flate specifically? The snap crate is a pure Rust snappy implementation.

[bstrie]

@BurntSushi If I had to guess, I'd say the purpose of this crate's inclusion is solely to operate on crate metadata. I wonder how hard it would be to go through and drop in several different implementations to benchmark different algorithms and settings.

[kennytm]

@est31 compiler-rt is imported as a submodule, so it is out-of-tree and off-topic for this issue I guess? Otherwise we would need to consider hoedown, jemalloc, graphviz and LLVM as well 😉.

[hanna-kruppe]

For how compression is used in the compiler, see #37086 for prior discussion and some experiments.

@kennytm @est31 Submodule or not, all these things are still dependencies and potentially merit discussion — just not in this issue since it's specifically about miniz.c. Separate issues might be worthwhile for some of them, and also for native libraries that get pulled in via crates.io dependencies (if any). But of those @kennytm named, hoedown is temporary, LLVM is 200% impractical to get rid of, graphviz AFAIK isn't a dependency (we have "libgraphviz" but AFAIK that's a pure-Rust implementation of writing out dot files). jemalloc might be interesting, once rust-lang/rfcs#1974 merges and alloc_jemalloc moves to crates.io, it will only be used internally by the compiler.

[Mark-Simulacrum]

miniz.c is no longer in the compiler. We've removed the in-compiler libflate, replacing with https://crates.io/crates/flate2, which itself does bind to it, but IMO that's outside the scope of tracking here, see rust-lang/flate2-rs#67.