Modified PeerConnection and WebRtcSession for end-to-end QuicDataChannel usage.

webrtc/api/quicdatachannel_unittest.cc

Index: webrtc/api/quicdatachannel_unittest.cc
diff --git a/webrtc/api/quicdatachannel_unittest.cc b/webrtc/api/quicdatachannel_unittest.cc
index 7245ccfa2177b54eb381c9da2b61dc6399602253..9a9a1db4a42dd2eb325383697c224d3b190d32e8 100644
--- a/webrtc/api/quicdatachannel_unittest.cc
+++ b/webrtc/api/quicdatachannel_unittest.cc
@@ -604,7 +604,7 @@ TEST_F(QuicDataChannelTest, DoesNotChangeStateWhenTransportChannelReconnects) {
 }
 
 // Tests that SetTransportChannel returns false when setting a NULL transport
-// channel or a transport channel that is not equivalent to the one already set.
+// channel.
 TEST_F(QuicDataChannelTest, SetTransportChannelReturnValue) {
   rtc::scoped_refptr<QuicDataChannel> data_channel =
       peer1_.CreateDataChannelWithTransportChannel(4, "label", "protocol");
@@ -614,7 +614,7 @@ TEST_F(QuicDataChannelTest, SetTransportChannelReturnValue) {
   EXPECT_TRUE(data_channel->SetTransportChannel(transport_channel));
   QuicTransportChannel* other_transport_channel =
       peer2_.quic_transport_channel();
-  EXPECT_FALSE(data_channel->SetTransportChannel(other_transport_channel));
+  EXPECT_TRUE(data_channel->SetTransportChannel(other_transport_channel));

[Taylor Brandstetter, 2016/07/21 23:39:57]

The old expectation seems correct to me, I don't think we want to allow a
QuicDataChannel to switch transports.

[pthatcher1, 2016/07/22 17:57:57]

As long as it hasn't been open yet, it might be OK.

 }
 
 // Tests that the QUIC message header is encoded with the correct number of