OkHttp Client stream and transport are tightly coupled

[carl-mastrangelo]

The interaction between the client stream and transport for OkHttp stream starting is tightly coupled. As brought up in #1294, we should take a look at how these two classes interact and make some clear boundaries (or possibly merge them).

[ejona86]

This will probably be partially resolved with the refactoring to make way for cronet support.

[ejona86]

@carl-mastrangelo, was this improved when I removed the Runnable? If not, it'd be helpful to point out some symptoms of the coupling.

[carl-mastrangelo]

• In start, it calls methods on the transport
• that method can then call back into the stream (with start(1234))
• the lock used by stream is actually the "lock" of transport
• transportHeadersReceived is called in by the transport, but must be called under the shared lock.
• sendCancel calls back into the transport
• remoteEndClosed does too

There are reasons for all this, but its still pretty coupled. It would be nice if calls only flowed from one to the other. Kun was the original person who brought this up, when I was adding the "start" method.