Relax handling of snappy content-encoding response header

[AlexKolpa]

With #5125 support for Snappy content compression was added, using the Accept-encoding: x-snappy-framed header. The choice for x-snappy-framed while correct from the spec does not really match up with how some modern frameworks such as Netty treat this, as most see the frame format as already implied and just return snappy. Netty specifically is flexible with the accept-encoding as long as it contains "snappy" (HttpContentCompressor), but returns the explicit Content-encoding: snappy. The current implementation in StreamDecoderFactories is however explicitly checking for x-snappy-framed being returned. This results in Armeria receiving a Snappy encoded stream, but seeing it as unencoded, leading to parsing issues down the line. I've created a small working example demonstrating this behavior

I think it makes sense to distinguish what Armeria passes as the accept-encoding header versus what it accepts in the content-encoding, being more lenient for both snappy and x-snappy-framed.

[jrhee17]

Hi, this looks like an issue - we may need a way to allow flexibility in how content can be decoded from either 1) each StreamDecoderFactory or 2) from DecodingClientBuilder.
I'm slightly leaning towards adding StreamDecoderFactory#matchesEncodingHeaderValue predicate.

Either way, I agree this should be fixed.