binder: Invoke onTransportReady() in a round-robin fashion.

[jdcormie]

Also call onTransportReady() only if isReady() still holds by the time
we get to a given Inbound. This dramatically reduces timeouts and
improves throughput when flow control has kicked in.

This approach is still not completely fair since each ongoing call might
consume a different amount of window on its turn, but because of the way
Outbound#writeMessageData() and BlockPool already work, everyone gets to
send at least 16kb.

Fixes #8834

[ejona86]

This may not be the best solution, but it is easy and reliable and better than what we have.

[ejona86]

nit: for changes like this it is helpful if the commit message would have a binder: prefix so the context is obvious.

[jdcormie]

nit: for changes like this it is helpful if the commit message would have a binder: prefix so the context is obvious.

good point done.

[jdcormie]

This may not be the best solution, but it is easy and reliable and better than what we have.

Yep thanks. The fact that ongoingCalls isn't navigable and can change between ACKs (and even while handleAcknowledgedBytes is running!) makes it tricky to do this using less memory per BinderTransport.

With respect to fairness, in a future PR we could consider sending one 16kb Binder transaction per Outbound in round robin order to achieve completely fair (unweighted) queuing. It's just a more invasive change. Also isn't clear to me where the call to io.grpc.internal.StreamListener#onReady() would fit into this.

[markb74]

Nice non-disruptive improvement!