websocket: refactor deflate encoder to fix sync flush failures

[jkarneges]

DeflateEncoder checks if the trailing 4 bytes bytes of flushed compressed output represents a sync marker (the code currently refers to these bytes as the "suffix"). This integrity check can fail due to the code incorrectly determining when the compressed output produced by miniz_oxide has completed, which seems to happen if miniz_oxide's input buffer is filled up prior to flushing, although there may be other ways for it to happen. This PR refactors DeflateEncoder::encode_step to properly detect the end of flushed output.

Currently, the way we determine the end of flushed output is when miniz_oxide's deflate function doesn't completely fill the provided output buffer after we have requested a sync flush once. This would seem like a reasonable approach, and it's even what flate2 does (flate2 wraps miniz_oxide). However, this approach appears to be wrong because miniz_oxide might not fully flush when asked to do so, resulting in less bytes being produced than what would fit in the provided output buffer even though there are more bytes remaining. Another sync flush request needs to be made for it to keep going.

My theory as to why multiple sync flush requests might be needed to receive all the output is that when miniz_oxide's input buffer is filled up, it is forced into producing output (until then it tries to accumulate input in order to compress the data better) and this forced production of output is internally implemented as a flush, and only one flush can be happening at a time, and so any sync request made while an "internal flush" is happening is ignored. I don't know if that's actually what's happening, but it certainly feels like it. In any case, the only way to ensure a requested flush happens is to request one in every call until it eventually does.

The yawc crate (a WebSocket lib) corroborates this apparent behavior. It uses flate2 but implements its own flush algorithm rather than using the one provided by flate2, and it works by requesting a sync flush in every call until a sync marker appears in the output.

This PR changes our flush algorithm to work similarly. It requests a sync flush on every call once it's what we want and then it determines when the output is complete based on the appearance of the sync marker bytes. That is, instead of determining completion some other way and confirming the trailing bytes are what we expect, the presence of the expected bytes in the output stream determines completion. As far as I can tell, this is the only reliable way to do it, at least with miniz_oxide and without a large output buffer. I don't know if other zlib-style libraries behave differently. I added some tests that fill miniz_oxide's buffer when compressing and they only pass with the fix.

As an aside, we may want to consider using flate2 instead of miniz_oxide directly, just like yawc, since its higher level API is optional and it's the more common entrypoint in the Rust ecosystem for deflate compression. However I'm a little hesitant since the main benefit in our case would be to support alternative zlib-compatible libs and I worry that could lead to behavior inconsistencies. If we ever want to do that, we'd need to be sure we are using the API defensively enough to work with all possible zlib backends.