Move gz API to libz-rs-sys-cdylib

[brian-pane]

No description provided.

[brian-pane]

This currently can compile the gz features with cd libz-rs-sys-cdylib && cargo build --features=gz but the build from the base directory fails due to the C and Rust allocators both being defined.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Flag	Coverage Δ
test-aarch64-apple-darwin	91.61% <100.00%> (+3.87%)	⬆️
test-x86_64-apple-darwin	91.18% <100.00%> (+4.21%)	⬆️
test-x86_64-unknown-linux-gnu	90.44% <100.00%> (+3.34%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
libz-rs-sys-cdylib/src/gz.rs	91.09% <100.00%> (ø)
libz-rs-sys/src/lib.rs	54.02% <ø> (-27.84%)	⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brian-pane]

With the change I just pushed, the basic build and tests work. If this approach looks safe, I'll troubleshoot the remaining issues with Clippy and fuzz tests.

[folkertdev]

let's explore this. I think one of the CI issues is that the cdylib crate should check in its Cargo.lock. There also appears to be some bug with the coverage profile in the fuzzers, but that is not triggered by this PR.

@bjorn3 do you have objections to this approach?

[brian-pane]

The cdylib's Cargo.lock is checked in, and I added a cargo fetch, but the cargo cinstall --offline --release --destdir=/tmp/cargo-cbuild-libz-rs step still fails because it can't find the libc crate.

Some of the other CI failures happen because both c-allocator and rust-allocator are enabled, but I don't know how the allocator configuration is supposed to work. This line in test-libz-rs-sys/Cargo.toml seems to turn on both allocators, but I can't see how that would work.

[folkertdev]

This line in test-libz-rs-sys/Cargo.toml seems to turn on both allocators, but I can't see how that would work.

It does work for zlib-rs (it just means: compile in both versions, rust has precedence but we do make sure it all compiles). It is only in libz-rs-sys that we disallow configuring both allocators.

[brian-pane]

I got the cargo-c dynamic library build working, but I'm stuck on the Clippy failures, which are due to both c-allocator and rust-allocator being defined. I can't tell where in the various Cargo.toml the conflicting allocators are getting enabled for libz-rs-sys.