Stricter annotation processor check now flags this use
If set, Content-Length header interferes with gzip compression.

The client expects the size of the post-compression data, but the app
sets the size of the pre-compression data.
close out the stream in the end.

This ensures that all the compressed content makes it to the end, as well as avoiding the native memory leak cause by GZIPOutputStream if it's left open.
Turns out the original test case was insufficient.

The test depends on the stricter client that refuses to read past the
Content-Length field. Turns out HttpURLConnection wasn't doing that, at
least as of 1.7u65 that I have on Ubuntu.

Apache Http Client seems to do that, exposing the problem.
Simplification
Using setHeader("Content-Encoding","gzip") as a trigger turns out problemaic

The code was originally using the act of setHeader("Content-Encoding","gzip") as a clue to transparently gzip-compress OutputStream.

Turns out this is problematic when we forward requests to other Servlets, which might come with its own gzip compression logic. JGit SmartHttpOutputStream was a good example of this. These implementations are correct on their own right because servlet spec doesn't make this a responsibility of the container.

In this change, CompressionFilter.activate() is used as a mechanism to trigger compression.
Updated test case to cover the actual problem.

The issue is that we need to work correctly both when (1) the transparent compression via filter is used, and (2) the application code decided to handle compression on its own.