"Fancy grpc interfaces" extensions; Pause, Flush and Cancel exposures

[TYoungSL]

Furthering the work done by #177, 2 additional extensions would be mechanisms to expose Pause/Resume (mutex to suspend read/write loop), Flush (wait until read/writes empty event), and Cancel (exposure of cancellation token source's cancel) functionality.

It's non-critical but nice to have. I expect I'd submit a PR when we run into these use cases.

If you're feeling "fancy" though, it's something to do. 🙂

[jamescourtney]

Would love to see a detailed proposal for this. Some offhand questions:

• Why not put the mutex on your side and just stop writing to the channels if that's necessary?
• All of the methods already accept a CancellationToken. What value does exposing the inner CancellationTokenSource have? It's linked to the parent token that is passed in. The only reason that one exists is to make sure that both Tasks exit when one of them hits an exception.

[TYoungSL]

It might all be extra work. The issue is an artifact from a meeting with @Rjvs. Will piece it together as we go.

Writing to the channel buffers is virtually instantaneous versus the channel writing to an RPC stream; cancellation/pause/resume should occur on both.

The linked cancellation token handles cancellation fine.

Pause and Resume were nice-to-haves that may come up when streaming with priorities or temporally relevant dependencies. (e.g. client sends an object X that refers to Y, server doesn't have Y and requests it asynchronously from client, client decides either it will tee up Y after X, suspend X to fill Y, or balance sending both. A representative scenario would be a mesh that has a material, and that material has textures. The mesh has normal priority, the material has highest priority, the textures have the lowest priority, but the server would request all of them as soon as it sees their references. The material is tiny, the mesh is large, the textures are large.)