Description
As of zlib-rs 0.5.0 (depended on by flate2 1.1.1), zlib-rs no longer exports C symbols by default, so it doesn't conflict with any other zlib that might be loaded into the address space.
This removes the primary issue that makes zlib selection a challenge that needs to be exposed to users: users may already have some other particular preference on zlib implementations, or want to use a system library, or want to ensure C dependencies use a particular zlib. Since zlib-rs 0.5.0 no longer conflicts with other zlib implementations, gix can make this choice independently and not create issues for the user.
Given that, I think it may make sense to use zlib-rs by default, for performance out of the box with no C compiler requirement. It may also make sense to drop the other variations, for simplicity and reduction in support burden. Prior to the next major version bump, this could happen by preserving them as dummy features with e.g. zlib-ng = [] and ignoring them, and at the next major version bump you could drop them entirely.
This would also mean that max-performance becomes the same as max-performance-safe, allowing simplification and eventual elimination of those options as well. You'd no longer need to provide guidance that tells libraries to carefully not activate some features while telling end users to be sure to activate them for performance; gix could provide maximum performance out-of-the-box.
Finally, this would mean that you could depend on flate2 with default-features = false, eliminating the miniz_oxide dependency. That would improve build time for everyone.
The primary downside of this approach would be that you'd always build zlib-rs. However, because this approach eliminates the build time of miniz_oxide, I think on balance this will end up not being a problem for build time.