Preventing a crash when the pacing bucket has a zero rate

This is a preventative fix for the case where the pacing bucket has
a zero rate.  We may want to continue investigating why the bucket
has a zero rate though (that can be a follow-up CL though).

This was a tricky one to track down as the crashes from the last 2
releases had optimized stacks which obfuscated the exact LOC which
was causing the divide by zero.  I looked back to our earlier
releases and found that this crash was occuring back then (lower
hit rate due to fewer connections using WebRTC back then) with the
same base stack but pointing to the LOC I am addressing in this CL.

Bug: 891725
Change-Id: Ic42e910614d35c683959b8c6e4417b0197a63818
Reviewed-on: https://chromium-review.googlesource.com/c/1258823Reviewed-by: Lambros Lambrou <lambroslambrou@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596309}

remoting/protocol/webrtc_frame_scheduler_simple.cc

@@ -191,9 +191,11 @@ bool WebrtcFrameSchedulerSimple::OnFrameCaptured(
   if (updated_area - updated_region_area_.Max() > kBigFrameThresholdPixels) {
     int expected_frame_size =
         updated_area * kEstimatedBytesPerMegapixel / kPixelsPerMegapixel;
-    base::TimeDelta expected_send_delay = base::TimeDelta::FromMicroseconds(
-        base::Time::kMicrosecondsPerSecond * expected_frame_size /
-        pacing_bucket_.rate());
+    base::TimeDelta expected_send_delay =
+        pacing_bucket_.rate() ? base::TimeDelta::FromMicroseconds(
+                                    base::Time::kMicrosecondsPerSecond *
+                                    expected_frame_size / pacing_bucket_.rate())
+                              : base::TimeDelta::Max();
     if (expected_send_delay > kTargetFrameInterval) {
       params_out->vpx_min_quantizer = kMaxQuantizer;
     }