optionally re-add the "write on async/await path" code rather than relying on the backlog; add supporting code for both; heartbeat should also help clear down anything in the backlog

seeing a lot of "MuxerIsCollected" failures on CI; it genuinely *is* collected in all local scenarios, so I'm suspicious that this is timing/load related; try to make it less twitchy

fix #1079 - make `RedisValue.Unbox` far more forgiving on inputs; also, make `RedisValue.Box` try to be more frugal (return boxed primitives rather than boxed RedisValue when possible; support reused objects for common values)

* remove the entire concept of the completion manager; it just doesn't make sense any more; everything async and external facing should be via the TP

* use "in" with ForAwait to avoid some extra copies

* experimental "backlog queue" approach

* Cleanup and de-dupe timeout exception data

* WriteMessageTakingWriteLockSync should consider backlog

* don't allocate all those strings

* this compiles, but nothing else; not tested yet

* fix the by-ref indexer

* record that CompletedSynchronously has changed - impacts a test

* update benchmarks and rev unofficial

* update to  pipelines 1.1.2 and simplify

* in debug mode, use a small page size in the arena

* rev pipelines to 1.1.3

* Update src/StackExchange.Redis/CommandTrace.cs
Co-Authored-By: mgravell <marc.gravell@gmail.com>

* Perf regression (#1076)

* compare baseline to 1.2.6

* remove the entire concept of the completion manager; it just doesn't make sense any more; everything async and external facing should be via the TP

* use "in" with ForAwait to avoid some extra copies

* experimental "backlog queue" approach

* Cleanup and de-dupe timeout exception data

* WriteMessageTakingWriteLockSync should consider backlog

* don't allocate all those strings

This is a documentation "fix" for #1061, so users are aware of the behavior.

Fixes #1074

# Conflicts:
#	toys/TestConsoleBaseline/TestConsoleBaseline.csproj

* compare baseline to 1.2.6

* remove the entire concept of the completion manager; it just doesn't make sense any more; everything async and external facing should be via the TP

* use "in" with ForAwait to avoid some extra copies

* experimental "backlog queue" approach

* Cleanup and de-dupe timeout exception data

* WriteMessageTakingWriteLockSync should consider backlog

* don't allocate all those strings

don't use the dedicated pool for the mutex await; that code path is from *app* code - we don't want to give them our threads

* simplify the whole result-box/TaskCompletionSource mess with the realization that the TCS *can be* the result-box, and simple (non-TCS) boxes can be [ThreadStatic]

* rev Pipelines.Sockets.Unofficial (removed AwaitableLockToken)

Replace SemaphoreSlim with MutexSlim, due to major impact from https://github.com/dotnet/corefx/issues/35393

* Remove obsolete responseTimeout setting

* fix bad autocomplete

* start work on a true async write path (no sync flush); at the moment only existing async code uses this - once stable, we can move more code to the full async path

* finish prep work before tackling subscriber lock (note: still lots of handshake options to asyncify)

* implement a background queue that represents the (necessarily ordered) subscription operations, rather than executing them synchronously (sync over async, locks, etc)

* Add pop functionality to sorted set (ZPOPMIN, ZPOPMAX)

* Add feature check for sorted set pop

* Add tests for sorted set pop

* Added: additional transaction conditions

* Fixed: failed tests
Added: tests for new transaction conditions

* Conflicts resolving

* Improve error messaging in unreachable-after-moved situation

We just want to log these - not fail builds on them.

Fix streams consumer group tests.

This doesn't change any expectations, only uses the much more useful overloads like Assert.Equal(a, b) instead of Assert.True(a == b) so we get much more useful output.

Something is wrong with our stream assumptions, but it's not super clear on what special IDs are what in the docuemtnation right now either...I think our resolution to special start IDs is off but let's get testing in order first.

We have concurrent run conflicts here it seems in the build - quick fixing stream names.