Don't let PRR kick in if there is less than a packets worth of bytes in

flight.

Merge internal change: 74165077

Renabled flaky LargePostZeroRTTFailure to see if this CL fixes issue
407756 on chromeos valgrind.

R=rch@chromium.org, rjshade@chromium.org
BUG=407756

Review URL: https://codereview.chromium.org/511003002

Cr-Commit-Position: refs/heads/master@{#292369}

net/quic/congestion_control/tcp_cubic_sender.cc

@@ -332,7 +332,7 @@ QuicTime::Delta TcpCubicSender::PrrTimeUntilSend(
     QuicByteCount bytes_in_flight) const {
   DCHECK(InRecovery());
   // Return QuicTime::Zero In order to ensure limited transmit always works.
-  if (prr_out_ == 0) {
+  if (prr_out_ == 0 || bytes_in_flight < kMaxSegmentSize) {
     return QuicTime::Delta::Zero();
   }
   if (SendWindow() > bytes_in_flight) {

net/tools/quic/end_to_end_test.cc

@@ -672,9 +672,7 @@ TEST_P(EndToEndTest, LargePostNoPacketLossWithDelayAndReordering) {
   EXPECT_EQ(kFooResponseBody, client_->SendCustomSynchronousRequest(request));
 }
 
-// TODO(rtenneti): This is flaky on ChromiumOS bots.
-// http://crbug.com/407756
-TEST_P(EndToEndTest, DISABLED_LargePostZeroRTTFailure) {
+TEST_P(EndToEndTest, LargePostZeroRTTFailure) {
   // Have the server accept 0-RTT without waiting a startup period.
   strike_register_no_startup_period_ = true;