Remove compress filter

[Jake-Shadle]

The compress filter makes no sense for Quilkin IMHO, and it's a special case that is inhibiting coming changes.

For context, the compress filter can both compress and decompress packets, using either brotli or lz4. However, Quilkin is a UDP proxy only, with no knowledge of packet contents other than what is configured for filters such as TokenRouter, Match, etc, it doesn't know anything about how individual packets might relate to one another. Since it operates on a packet level, and assuming an MTU of 1500 (ethernet), the benefits of both compression and decompression use cases are practically worthless.

In the compression case, the savings are generally going to be minimal at such small sizes due the overhead of the compression header.

In the decompression case, it's possible for a packet to decompress to size larger than the MTU, causing it to fragment and thus have increased likelihood of the packet(s) being dropped during transit to their destination.

The only use case I can think of where compression/decompression would be useful for Quilkin to implement is in a situation where neither the client or server implementation is controlled by the entity proxying the traffic, and one side requires compression that the other side doesn't support. I'm skeptical this use case exists.

Leave a comment if you actually do use this filter and why, but if no one does by the end of January next year, I think we should remove it, removing a special case and getting rid of dependencies, improving compile times.