substantial GC overhead with per message deflate compression

[y3llowcake]

I'm noticing a large spikes in heap allocs and GC time when message write volume is high.
My profiles lead me towards flate.NewWriter() in compressNoContextTakeover().

I believe this is causing an allocation of a new sliding window (32k?) for each compressed write. This seems avoidable if the writers are recycled via flate.Writer.Reset().

Probably should be statically allocating the flate writer per connection and also provide an option to get flate writers from a sync.pool.

[garyburd]

Start by using a sync.Pool for flate writers and see how that works. I want to avoid adding new knobs in the API.

[y3llowcake]

#194

[y3llowcake]

readers: #195

[garyburd]

Fixed by 2db2f66 and 3ab3a8b.