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).
Without this, the Follower would see data for subchannel 0 before it had a
chance to create the SubChannel object that could accept it. We already have
a mechanism for inbound data to be queued inside the SubChannel until the
endpoint has had a chance to create the Protocol object: we rely on that
mechanism here. We just need to create the SubChannel before telling the
Manager to start, even though we don't reveal the SubChannel to the
caller (via the control endpoint) until the connection is known to succeed.
This helps a manual test get data from one side to the other without throwing
exceptions.
This is only used by tests so far (and will simplify the integration test
that hasn't landed yet), but is not yet wired up to Boss, so there's no way
for applications to enable it yet.
