Additional fix for race when timout put to mailbox, then timeout cancelled and subscribe succeeds.
So it could happen, that JUST BEFORE `subscriptionTimeout.cancel()` the
`SubstreamSubscriptionTimeout` was already put into the actor's mailbox,
the cancelling then kicks in (does nothing) and then the attaching of
the subscriber kicks in, it passes OK. So the actor gets the timeout
first and then the subscription... So the publisher is already
subscribed to by some subsciber. But now the actor gets the
SubstreamSubscriptionTimeout message, and wants to subscribe the
cancelling subscriber to it. The publisher can only handle 1 subscriber,
so attaching of the cancelling subscriber will fail - well this is not
very bad, because it will just onError the cancelling subscriber rigth
away, but it can be missleading because the debug log will contain the
"cancelling... after..." message, while it has not REALLY cancelled it.
The isAttached can not be added to handleSubscriptionTimeout because
there it's "too late" and the log message would already be sent..
So while writing this up I noticed that it's not an "error race", but
it's still a race we could avoid when putting this isAttached check
before cancelling the publisher... do you think it's worth it?
The completeSubstreamOutput is used to not early complete the stream,
where as invalidating would shutdown the stream too early (and elements
wouldn't be emitted as expected).
* had to change api because of trait+object not useable from java
* ActorSubscriber.RequestStrategy and its implementations moved to
top level
* messages moved to ActorSubscriberMessage and ActorPublisherMessage
object
