ExecutorMixin should cover signals sent by ConnectionAutomaton as well.

We have to order them w.r.t. signals sent by the clients, and the cleanest way to do it is to allow ExecutorMixin to handle it.

I reviewed the code and it doesn't seem to be needed... ever. Here is why:

• the only time when stream automaton calls into connection automaton and may be callled back synchronously is the termination sequence,
• stream automatons manage State (closed, open, etc.) as it if was a WAL, i.e. modify state, send signals afterwards,
• endStream is a no-op if stream automaton is already closed.

We control both stream and connection automatons, hence we can afford to have negligibly more fragile implementation here.

I may crack out this logic around state management in an automaton into a mixin. Not important right now.