The previous implementation would call the control/receiving Protocol
completely backwards: dataReceived first, then connectionLost, then finally
connectionMade. Which didn't work at all, of course.
Anyone sending 4GB in a single `transport.write()` is in for a surprise, but
at least we'll surprise them with an assertion *before* spending the time and
memory encrypting that monster.
I think I just managed to forget that inbound_close requires we respond with
a close ourselves. Also outbound open means we must add the subchannel to the
inbound table, so we can receive any data on it at all.
I'm sure I had a good reason for avoiding integers, but it makes logging and
testing more difficult, and both sides are using integers to generate them
anyways (so one side can pick the odd ones, and the other can pick the even
ones).
