Use partial flushes with miniz_oxide backend

[fintelia]

I'll admit that I don't quite know why the code previously mapped FlushCompress::Partial to a sync flush

[Byron]

Thanks a lot for looking into this!

I think it's best to validate this change, which to my mind should be good.

[Byron]

@oyvindln Do you know if there was a reason not to use partial flushes before? If not, then it's probably safe to map it 1:1, but I wanted to check with you.
Thanks for your help!

[oyvindln]

I have no idea - would have to look into it

[Byron]

I looked into it by digging through the history, and it's unclear why things are the way they are.

There was a time when there was direct conversion.

        flush: FlushCompress,
    ) -> Result<Status, CompressError> {
        let flush = MZFlush::new(flush as i32).unwrap();

The revision that actually introduced this line didn't mention why either.

So I think it's fair to merge this.

[Byron]

After double-checking, I don't think we can find out why not to do it, without any indication of why that is in the Git history.

[CosminPerRam]

Hey, this was done in #462, I mapped it this way because of the MZFlush::new i32 constructor (1 | 2 => MZFlush::Sync).

FlushCompress::Partial is 1, Sync is 2, so therefore this mapping (which kept original behaviour).

[fintelia]

Yes, I discovered after this PR that miniz_oxide didn't support partial flushes, so I added them in Frommi/miniz_oxide#179. Thus, flate2 should avoid shipping this change until miniz_oxide makes a new release and this crate's version dependency is updated accordingly. With this change and the patch to miniz_oxide, #498 confirms that all backends implement all the flush types properly (at least for the one specific input that is tested).

(Someone should also probably make a PR to update the 1 | 2 => MZFlush::Sync line in miniz_oxide, I missed it when making my PR)