fix pathological case when consuming *really really* buffers (SMEMBERS on 5M rows for example) - have BufferReader keep a SequencePosition "snapshot", and compute sub-buffers using that

(also fixes bug where LoggingPipe wasn't using the right thresholds, but that's a debug tool only)

Make SetPopMultiple available on RedisFeatures; use in test; test for explicit single SPOP; add fast zero SPOP

fix #875 - string encode was failing to encode correctly (also make more consistent use of GetReference)

This API was missing - resolves #203

This may just not make sense anymore, but let's log and look at the numbers.

Resolves #855

Twemproxy handles this internally - we were incorrectly blocking it.

This was correct before, not sure how we convinced ourselves otherwise. I added additional verification checks to the tests.

Ensure that pre-handshake backlog is completed successfully; also simplify how sent messages get the exception recorded; can massively simplify if we know we've already burned the connection

Known breaking change and intended for 2.0. See #809 for details - pretty much for unit testing.

Better handling for null an empty values to SetRemove(Async), Redis will throw here so there's no reason we can't gracefully hamdle it better.

This is interesting, and may explain some other hangs. Previously, arr was null, and the .Length call in the MultiBulk case was throwing a null ref. This doesn't throw externally through, it just runs forever. While there's a timeout guard against this on the ExecuteSync path, there's not on ExecuteAsync. This is easy to reproduce for example add this at the top of the result processor:

if (result.Type == ResultType.MultiBulk) throw new Exception("Woops");

...and we'll only see timeouts on sync and forever runs on async. I left this code in (commented) for an easy repro case.

/cc @mgravell

This isn't the source of our timeouts...as there aren't running. But cleaning up usages.

Turns out @mgravell really really liked "foo" and "hashset" years ago =P

ackowledge that we can timeout while waiting to get on the write queue; up the sync timeout default; rename Queue=>Write - we don't have a queue any more

TL;DR: This behaves different on a redis server running on Linux vs. Windows.