Enable gzip compression for console and webapps when client != 127.0.0.1

[Reportage]

In order to make accessing the console over the network more responsive, enabling gzip compression should be considered. If the console (or anything served via the default jetty) is accessed on localhost, gzip isn't needed. If the console is accessed via any other address, gzip could be enabled for clients that support it. This could either be automatic, or via a preference / UI option. Conditional compression for standalone snark might also be worth enabling.

[zzz]

Not a common use case, very few people do remote console.
Not sure if it would be easy or even possible to do it only if not local.
If it's all or none, probably not worth the increased CPU for local compression.
Low priority unless somebody really needs it.

[Reportage]

CPU usage should be fairly light if compression is limited to html/css/js/svg. Initially, a preference/UI option to enable gzip on the console and webapps would allow a better assessment of usefulness/performance. Remote access of webapps would also benefit, not least I2PSnark. Potential for +-80% shrinkage on some of the content.

[zzz]

Right, to assess the usefulness/performance and decide whether to implement it, we have to implement it.

[Reportage]

Not much to do on the implementation front, as gzip compression is already enabled for the http server tunnel, so more a question of cut and paste.

[zzz]

Incorrect. The HTTP server tunnel has nothing to do with the console.

[zzz]

One other justification - pure speculation - that with HTTPS console (#2160), compression before encryption may be cheaper than encryption of something far larger.

In 019010cf4eb46dff5e7f2761aaf2fb30eb21abcd 0.9.33-14, configured as follows:

• enabled by default, disable with adv. config routerconsole.enableCompression=false
• 64KB minimum size to compress, unless chunked, but almost all HTML output is chunked
• only for mime types text/plain, text/html, text/css, and similar
• not dependent on source IP

I didn't look at the source IP, because one of the most beneficial use cases would be ssh tunneling, where it would be localhost anyway

[zzz]

On further testing, the logic described above was not implemented correctly.
Fixed in 3ce719d6d83e0f6781efe1194f5badf63f23d167 to be 0.9.33-15