TransportController refactoring.

TransportController refactoring.

Getting rid of TransportProxy, and in its place adding a
TransportController class which will facilitate access to and manage
the lifetimes of Transports. These Transports will now be accessed
solely from the worker thread, simplifying their implementation.

This refactoring also pulls Transport-related code out of BaseSession.
Which means that BaseChannels will now rely on the TransportController
interface to create channels, rather than BaseSession.

Committed: https://crrev.com/47ee2f3b9f33e8938948c482c921d4e13a3acd83
Cr-Commit-Position: refs/heads/master@{#10022}

[Taylor Brandstetter, 2015-09-19 00:00:25]

deadbeef@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[Taylor Brandstetter, 2015-09-19 00:00:26]

https://codereview.webrtc.org/1350523003/diff/1/webrtc/p2p/base/transport.cc
File webrtc/p2p/base/transport.cc (right):

https://codereview.webrtc.org/1350523003/diff/1/webrtc/p2p/base/transport.cc#...
webrtc/p2p/base/transport.cc:507: }
I got rid of this because it was a code path that was never hit. Candidate
gathering only started in Connect(), which means connect_requested_ was always
true here.

[pthatcher1, 2015-09-19 00:08:05]

https://codereview.webrtc.org/1350523003/diff/20001/webrtc/p2p/base/faketrans...
File webrtc/p2p/base/faketransportcontroller.h (right):

https://codereview.webrtc.org/1350523003/diff/20001/webrtc/p2p/base/faketrans...
webrtc/p2p/base/faketransportcontroller.h:527: transport->MaybeStartGathering();
Do we want the FakeTransportController to auto-gather, but the real one to not? 
What would happen if we removed this line?

https://codereview.webrtc.org/1350523003/diff/20001/webrtc/p2p/base/p2ptransp...
File webrtc/p2p/base/p2ptransportchannel.cc (right):

https://codereview.webrtc.org/1350523003/diff/20001/webrtc/p2p/base/p2ptransp...
webrtc/p2p/base/p2ptransportchannel.cc:306: need_to_gather_candidates_ = true;
What if we use "gathering_state_ = new;" instead?

[pthatcher1, 2015-09-19 00:56:20]

lgtm

[Taylor Brandstetter, 2015-09-19 00:59:23]

https://codereview.webrtc.org/1350523003/diff/20001/webrtc/p2p/base/faketrans...
File webrtc/p2p/base/faketransportcontroller.h (right):

https://codereview.webrtc.org/1350523003/diff/20001/webrtc/p2p/base/faketrans...
webrtc/p2p/base/faketransportcontroller.h:527: transport->MaybeStartGathering();
On 2015/09/19 00:08:05, pthatcher1 wrote:
> Do we want the FakeTransportController to auto-gather, but the real one to
not? 
> What would happen if we removed this line?

This is something that only gets called in a test environment, as a convenience
to get two PCs connected. So I think it's fine as-is.

[Taylor Brandstetter, 2015-09-22 18:58:48]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2015-09-22 18:58:49]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1350523003/#ps100001 (title:
"Fixing Mac test.")

[commit-bot: I haz the power, 2015-09-22 18:59:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1350523003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1350523003/100001

[commit-bot: I haz the power, 2015-09-22 19:40:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-22 19:40:47]

Try jobs failed on following builders:
  win_drmemory_light on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/win_drmemory_light/buil...)

[Taylor Brandstetter, 2015-09-22 19:45:25]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2015-09-22 19:45:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1350523003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1350523003/100001

[commit-bot: I haz the power, 2015-09-22 19:53:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-09-22 19:53:28]

Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[Taylor Brandstetter, 2015-09-22 21:48:13]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2015-09-22 21:48:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1350523003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1350523003/100001

[commit-bot: I haz the power, 2015-09-22 22:08:29]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-09-22 22:08:47]

Patchset 6 (id:??) landed as
https://crrev.com/47ee2f3b9f33e8938948c482c921d4e13a3acd83
Cr-Commit-Position: refs/heads/master@{#10022}

[torbjorng (webrtc), 2015-09-23 09:16:28]

A revert of this CL (patchset #6 id:100001) has been created in
https://codereview.webrtc.org/1358413003/ by torbjorng@webrtc.org.

The reason for reverting is: This CL causes problems with the WebRTC-in-Chromium
FYI bots. Presumably it needs to be done in several steps, where removed files
are emptied instead of removed in the first step..