Drop checks for unsound null values

[natebosch]

Towards dart-lang/tools#1771

During the null safety migration it was possible for
StreamSubscription.cancel() to return null in some cases. Now that
this package is only used with sound null safe code it isn't possible
for these nulls to flow through anymore so it is not necessary to filter
for them.

[lrhn]

This pause happens only if the current stream is broadcast, and the trigger stream is not.

If this stream is a broadcast stream, then its emissions shouldn't depend on whether it has subscribers or not,
and I'd not pause the triggerSub here. Or valueSub for that matter.
There should be no difference for someone who listens, cancels and listens again whethere there are other listeners at the same time. Which means that even if both streams are broadcast streams, cancelling and resubscribing isn't the same as staying subscribed, because the state can depend on all the prior value events and on whether the last event was at trigger or a value.

If this stream is not broadcast, then nothing ever needs to happen after cancel, and we should cancel triggerSub too, so that's fine.

I'd make this:

controler.onCancel = () {
  if (!isBroadcast) {
    if (isValueDone) {
      if (isTriggerDone) return null;
      return triggerSub.cancel();
    } 
    if (isTriggerDone) return triggerSub!.cancel();
    return [valueSub!.cancel(), triggerSub!.cancel()].wait.then((_) => null);
  }
};

(Probably no need to set the ...Sub variables to null. Nothing holds on to a cancelled completer.)

Then onListen should not assume that it starts from scratch if it's called a second time on a broadcast stream. It should probably just do nothing the second time.

Also noticed: onEmpty should probably not be required if longPoll: true makes it not be used.
Making it optional, and then not emitting anything on a longPoll:false empty trigger would be consistent. You get a value when you ask for one, if there is one.
Or make longPoll the behavior when onEmpty == null;, instead of asking for it and then also passing an unusable onEmpty.
Or keep onEmpty required, and use it if a longPoll is active when the values stream closes.

[lrhn]

(Just for the heck of it, here is a complete rewrite: https://dartpad.dev/?id=c834bfd326ab1341903145bb9e32bfa7
It moves almost everything inside onListen, which avoids some nullable types, and it wraps user function calls in try/catch.)
Completely untested.

[natebosch]

It doesn't pass the tests as-is, but there could be tests which are overly coupled to the particular async event interleaving. Maybe file this as an issue to consider?