use zlib-rs for crc32 (when available)

[folkertdev]

This currently hits a bug in the zlib-rs implementation that we don't run into internally, but that the public API does. So, I'll need to go fix that. But hopefully this gives an impression what it'll look like.

[folkertdev]

Unfortunately this library exposing a Crc::combine means we can't (to my knowledge) directly use our Crc32Fold. It has some optimizations that make it very performant for large chunks, and for incremental updating, but they make it impossible to arbitrarily advance the state.

There is probably some way around that in zlib-rs, but I think it would impact our performance for the cases that we care about. Anyhow, what I've implemented now is conceptually no worse than what crc-fast and crc32fast do, so I think it should be fine.

[folkertdev]

With that this should be OK to merge. We might change the path of where the crc are exported at some point in the future, but that should be straightforward to handle when bumping the dependency version in flate2.

[Byron]

It seems you have been nerd-sniped here, and… I know that feeling :).

But let me start with: This is awesome, and thanks so much, I can't wait for this to be merged. However, I haven't looked at the PR yet because I think it could be rebased onto #527 once that is merged. Could you take a look to see if that would truly be reducing risk? Or maybe #527 could be improved even.

Oh, and if you want, would it be possible to add a cargo tree invocation to CI that checks that with a specific set of features, there will be no crc-fast crate anymore? Probably a negative test is fine and easiest. If not, I'd add that before merging as it's another point of this PR which I think should be tested.

[folkertdev]

It seems you have been nerd-sniped here

I had thought about it before, but yes.

Could you take a look to see if that would truly be reducing risk?

Those tests are useful just to generally make sure the crc looks good. In this PR I'm also testing the public API (both with crc32fast and without), so that even the parts that flate2 itself does not currently use don't silently regress.

would it be possible to add a cargo tree invocation to CI

Yes, I added one.

[Byron]

Thanks a lot, I think that's it!