This has been tried before with very unfortunate side effects (see, for instance, the tale of woe that is T125938), but, this time we would try it without involving Mediawiki, PHP, or even Apache.
Envoy itself has a Compressor filter. This is worth experimenting with; hopefully responses compressed by it are more compatible with ats-be and varnish-fe, and it would also allow us to sidestep previously-buggy Mediawiki output generation code, etc.
We wouldn't want to send the same Accept-Encoding header upstream to Apache/Mediawiki. Envoy's Compressor configuration accepts a remove_accept_encoding_header Boolean, so that's easy enough.
Open questions here involve figuring out the appropriate testing to do and the best mechanism for a canary deployment.
(Later on, in the far future, there's potentially-tricky possible work in balancing between gzip and Brotli compression, but for now, gzip is the only thing supported by either Envoy or ATS.)