Use native Okio copy for retrying.

[JakeWharton]

For your consideration and review, because this has a slight behavioral problem...

This method is called from two places in two different ways:

• SpdyTransport.writeRequestBody calls it with an instance of SpdyDataSink. This class is a Sink implementation which adds framing around a SPDY FrameWriter who ultimately delegates to a BufferedSink around the Socket.
• HttpConnection.writeRequestBody on the other hand passes a BufferedSink which is directly wrapped around the Socket.

The distinction of the former being a Sink and the latter being a BufferedSink means that Okio.buffer is going to behave differently. When we ultimately call .emit() to ensure we're not leaking segments, one writes directly to a Socket whereas the other hands off to another Buffer and lets emission to the socket happen at the discretion of that sink.

So, are we fine with that behavior? Do we revert Okio's behavior?

[JakeWharton]

One way to work around this behavior would be to do a single-Buffer write.

Buffer buffer = new Buffer();
thing.copyTo(buffer);
sink.write(buffer, buffer.size());

[swankjesse]

I'd still like to revert Okio's behavior.

[swankjesse]

... but overall, I want Okio users to not have to think about where the buffer bytes are being stranded. Whatever we do should focus on that.

[JakeWharton]

We should do that ASAP then.

[JakeWharton]

LGTY now that we're Okio 1.2.0-ing all up in this piece?

[swankjesse]

I don't think the BufferedSource here helps?

Buffer buffer = new Buffer();
content.copyTo(buffer, 0, content.size());
socketOut.write(buffer, buffer.size());

[swankjesse]

I don't really get what the motivation is here. Is clone() slower than copyTo or something?

[JakeWharton]

I asked you that very same question a few weeks ago but I think our conversation got derailed.

[swankjesse]

Cool. As it stands now, I don't think this changes behavior. LGTM.