Changes look good so far. A couple of nitpicks and a posible problem:
In the 0-10 Connection class there was a private implementation of TransportActivity added, but it isnt used. The updated connect() call passes null, which looks unsafe at first when following the subsequent method calls in IoNetowrkTransport but ultimately ends up being ok (because we dont set the reader/writer idle times at all on the 0-10 client side and rely on reflecting the brokers heartbeats if any) but possibly means we are doing socket timesouts with no effect. Given the IoReceiver ignores the ticker if it is null, could we just not create one if we arent going to really use it (as happens in the existing but now-unused IoNetworkConnection constructor)?
In IdleTimeoutTicker it might be nicer if instead of checking !=0 it used >0 as happens elsewhere.
Since IdleTimeoutTicker.tick() is only called when we get a SocketTimeoutException in IoReceiver, doesnt that mean its possible we can be in a writer-idle situation and yet never signal so (if the reader keeps getting data within its timeout, which is twice as long as the senders)? The old 0-8/9/9-1 clients will happily kill the connection in this situation if the broker doenst send them anything.