Add MetricsProvider::OnAppEnterBackground callback.

components/metrics/metrics_provider.h

Index: components/metrics/metrics_provider.h
diff --git a/components/metrics/metrics_provider.h b/components/metrics/metrics_provider.h
index 6a690f5251c893f7853e4f466cff590e611b011f..030540e1ae2672eac6bd41404f3827b77c71f42d 100644
--- a/components/metrics/metrics_provider.h
+++ b/components/metrics/metrics_provider.h
@@ -36,6 +36,13 @@ class MetricsProvider {
   // Called when metrics recording has been disabled.
   virtual void OnRecordingDisabled();
 
+  // Called when the application is going into background mode, on platforms
+  // where applications may be killed when going into the background (Android,
+  // iOS). Providers that buffer histogram data in memory should persist
+  // histograms in this callback or in the subsequent Provide* callbacks, as the
+  // application may be killed without further notification after this callback.

[Alexei Svitkine (slow), 2016/07/27 17:41:11]

This seems OK for now, but note that we do have plans to persist metrics even in
the case of a crash with bcwhite@'s persistent metrics work.

[Bryan McQuade, 2016/07/27 18:25:15]

Yeah - I think any subsystem that does buffering is going to continue to have to
accept data loss due to crashes. That's an acceptable tradeoff for us - there
are certain metrics that we only want to log once we've collected enough
information, and we accept that a low loss rate due to browser process crashes
is acceptable.

But we can at least flush those metrics when the app goes into the background,
using this callback. So I think this will continue to be beneficial for us even
with bcwhite's persistent metrics.

+  virtual void OnAppEnterBackground();
+
   // Provides additional metrics into the system profile.
   virtual void ProvideSystemProfileMetrics(
       SystemProfileProto* system_profile_proto);