It looks like maintainers aren't very active on the repo
and https://github.com/nytimes/gziphandler/pull/107 has come to a standstill.
I don't want to wait forever for this to go in. Let's use a replace directive
to point to the fork. When the PR gets merged, we can just bump the dependency
and remove the replace directive.
Re: the PR, copying the text from the PR description
This gives 40-50% improvements in CPU with very minor increase
in memory, just as a drop-in replacement. I think that is a very reasonable tradeoff.
The library is mature and safe to be used in production.
```
name old time/op new time/op delta
GzipHandler_S2k-8 74.9µs ± 2% 34.4µs ± 2% -54.07% (p=0.000 n=10+9)
GzipHandler_S20k-8 379µs ± 1% 226µs ± 3% -40.42% (p=0.000 n=9+10)
GzipHandler_S100k-8 1.95ms ± 2% 1.15ms ± 1% -41.27% (p=0.000 n=9+9)
GzipHandler_P2k-8 24.3µs ±25% 10.7µs ±25% -55.80% (p=0.000 n=10+10)
GzipHandler_P20k-8 132µs ± 2% 75µs ± 1% -42.95% (p=0.000 n=9+10)
GzipHandler_P100k-8 658µs ± 2% 371µs ± 3% -43.68% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
GzipHandler_S2k-8 7.71kB ± 5% 9.13kB ± 7% +18.33% (p=0.000 n=10+10)
GzipHandler_S20k-8 65.1kB ± 3% 70.3kB ± 3% +8.05% (p=0.000 n=10+10)
GzipHandler_S100k-8 348kB ± 4% 382kB ± 2% +9.85% (p=0.000 n=10+10)
GzipHandler_P2k-8 7.60kB ± 1% 7.93kB ± 2% +4.33% (p=0.000 n=10+10)
GzipHandler_P20k-8 64.4kB ± 1% 66.3kB ± 2% +2.92% (p=0.000 n=10+10)
GzipHandler_P100k-8 304kB ± 1% 309kB ± 1% +1.67% (p=0.000 n=10+9)
name old allocs/op new allocs/op delta
GzipHandler_S2k-8 21.0 ± 0% 21.0 ± 0% ~ (all equal)
GzipHandler_S20k-8 24.0 ± 0% 24.0 ± 0% ~ (all equal)
GzipHandler_S100k-8 27.0 ± 0% 27.0 ± 0% ~ (all equal)
GzipHandler_P2k-8 21.0 ± 0% 21.0 ± 0% ~ (all equal)
GzipHandler_P20k-8 24.0 ± 0% 24.0 ± 0% ~ (all equal)
GzipHandler_P100k-8 26.0 ± 0% 26.0 ± 0% ~ (all equal)
```
https://mattermost.atlassian.net/browse/MM-28491
96a3407b7a