Rename kBeta to be unique (net/)

When building using Jumbo unnamed namespaces gets merged
and variables with the same name conflict. This happens
for the variables kBeta in:
net/third_party/quic/core/congestion_control/cubic_bytes.cc
net/third_party/quic/core/congestion_control/rtt_stats.cc

This commit solves the issue by renaming kBeta in
net/third_party/quic/core/congestion_control/cubic_bytes.cc
to kDefaultCubicBackoffFactor to avoid the conflict and
to give the variable a more descriptive name.

Bug: 772146
Change-Id: Ibc2e6732d2c5fa70672a73e7b6669d8b71f581d1
Reviewed-on: https://chromium-review.googlesource.com/1119691
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Oscar Johansson <oscarj@opera.com>
Cr-Commit-Position: refs/heads/master@{#571452}
diff --git a/net/third_party/quic/core/congestion_control/cubic_bytes.cc b/net/third_party/quic/core/congestion_control/cubic_bytes.cc
index 34b735b..ff5695b 100644
--- a/net/third_party/quic/core/congestion_control/cubic_bytes.cc
+++ b/net/third_party/quic/core/congestion_control/cubic_bytes.cc
@@ -29,7 +29,7 @@
     (UINT64_C(1) << kCubeScale) / kCubeCongestionWindowScale / kDefaultTCPMSS;
 
 const uint32_t kDefaultNumConnections = 2;
-const float kBeta = 0.7f;  // Default Cubic backoff factor.
+const float kDefaultCubicBackoffFactor = 0.7f;  // Default Cubic backoff factor.
 // Additional backoff factor when loss occurs in the concave part of the Cubic
 // curve. This additional backoff factor is expected to give up bandwidth to
 // new concurrent flows and speed up convergence.
@@ -61,7 +61,7 @@
   // emulation, which emulates the effective backoff of an ensemble of N
   // TCP-Reno connections on a single loss event. The effective multiplier is
   // computed as:
-  return (num_connections_ - 1 + kBeta) / num_connections_;
+  return (num_connections_ - 1 + kDefaultCubicBackoffFactor) / num_connections_;
 }
 
 float CubicBytes::BetaLastMax() const {