Test/Operator Modernization

[JakenVeina]

So, with most of theboutstanding issues and feature requests cleared out, I'm interested in dong some pro-active maintenance work, I.E. seeking out bug and enhancements in the existing codebase.

The way to do this, I figure, is to focus on enhancing test thoroughness, across existing operators. There's a few things we've talked about in passing, over the last couple years, that we'd like to be consistent about:

1. Error propagation
   1.1. Errors in source streams should virtually always propagate downstream, particularly in scenarios where there are multiple source streams, or child streams, involved.
   1.2. Exceptions thrown by delegates should be caught and forwarded downstream.
   1.3. .SubscribeSafe() should be used to ensure that immediate exceptions get caught and forwarded downstream.
2. Completion propagation
   2.1. Downstream completion should, generally, wait for all upstream completions to occur. What this means specifically will vary from operator to operator, but ultimately, a completion should occur when there is no possibility for further "next" notifications to occur.
3. Empty changesets
   3.1. Operators should always forward an initial changeset, even when empty, and even when the operator otherwise suppresses empty changesets.
   3.1.1. That's not to say that operators should publish an initial changeset upon subscription, like source collections do, they should just respond to the first changeset they see by always emitting at least an empty changeset.
   3.2. Operators should generally suppress empty changesets after the initial changeset. Exceptions include operators where an option for this is specified by the consumer, or the operator documents otherwise.
4. Changeset consolidation
   4.1. Operators should generate at most one downstream changeset for each upstream notification.
   4.2. @dwcullop proposed recently that we could even do better than this: that when a notification comes in while another is being processed, and has to wait, it can signal to the first notification to hold its changeset, so the second notification can add on to it. Thoughts?
5. Changeset correctness
   5.1. Basically, use .ValidateChangeSets() downstream of operators being tested. This verifies that key values are always correct, items are never removed before being added, etc.
6. Notification correctness
   6.1. Notification sequencing, I.E. "only one error or completion notification can occur, and those should end the stream." This theoretically shouldn't be an issue, so long as we're using System.Reactive base types, but being explicit helps make us future-proof.
   6.2. Notification synchronization, I.E. notifications coming out of a stream should be serialized. I.E. any operator that consumes multiple source streams needs to be exercised for multi-thread safety, along with use of .ValidateSynchronization().

I think that's everything I've had on my mind. @dwcullop @RolandPheasant I'd like to lake sure we're all in agreement on these points before I really start digging into writing new tests.