Add encoding primitives and a compression middleware

[tmattio]

This essentially upstreams dream-encoding.

It adds a new dependency on decompress.

Two new middleware are added:

• Dream.compress
• Dream.decompress

And we add a new Encoding section to the API with the following functions:

• Dream.with_encoded_body
• Dream.accepted_encodings
• Dream.accepted_encodings_with_weights
• Dream.content_encodings
• Dream.preferred_content_encoding

I'm happy to keep this in a separate package, I'm opening a PR in case you're interested in having this upstream, but don't hesitate to close the PR if that's outside of the scope of first-class features you see.

[aantron]

Thanks! I see an argument for not having this in Dream, which is this, or variants of this, are also needed on the client side (i.e., in Hyper).

[aantron]

Why is this file in src/unix/? Can't we do compression/decompression "purely," i.e. in memory?

[aantron]

Note: it should be possible to have a streaming compressor/decompressor with the current Dream API. I will probably write an example that does a streaming transformation of a body stream in some way, and a compressor/decompressor would be built analogously.

[aantron]

(Same note here about streaming)

[aantron]

Thanks! I see an argument for not having this in Dream, which is this, or variants of this, are also needed on the client side (i.e., in Hyper).

There are dream-pure and dream-httpaf, which are used by both Dream and Hyper, even though they are in this repo, so maybe the core machinery in this PR can still be upstreamed to this repo into a similar shared package, but the functionality probably needs to be exposed in both Dream and Hyper.

OTOH, how much common functionality is there? For example, as I understand it, handling Accept-Encoding headers is only needed on the server. We probably need to sketch out the client versions of these middlewares, to see if there are any substantial common helpers, beyond just using common third-party compression libraries.