Change the meaning of MobileSessionShutdownType's FIRST_LAUNCH_AFTER_UPGRADE bucket.

ios/chrome/browser/metrics/ios_stability_metrics_provider.mm

Index: ios/chrome/browser/metrics/ios_stability_metrics_provider.mm
diff --git a/ios/chrome/browser/metrics/ios_stability_metrics_provider.mm b/ios/chrome/browser/metrics/ios_stability_metrics_provider.mm
index cc1af0be6c364d41ee19695630f379f62a5b78ab..8d8050daa00e32e48af72b28852d03254da7c3d3 100644
--- a/ios/chrome/browser/metrics/ios_stability_metrics_provider.mm
+++ b/ios/chrome/browser/metrics/ios_stability_metrics_provider.mm
@@ -38,14 +38,6 @@ bool IOSStabilityMetricsProvider::HasInitialStabilityMetrics() {
 
 void IOSStabilityMetricsProvider::ProvideInitialStabilityMetrics(
     metrics::SystemProfileProto* system_profile_proto) {
-  // If this is the first launch after an upgrade, existing crash reports
-  // may have been deleted before this code runs, so log this case in its
-  // own bucket.
-  if (IsFirstLaunchAfterUpgrade()) {
-    LogShutdownType(FIRST_LAUNCH_AFTER_UPGRADE);
-    return;
-  }
-
   // If the last app lifetime did not end with a crash, then log it as a
   // normal shutdown while in the background.
   if (metrics_service_->WasLastShutdownClean()) {
@@ -53,6 +45,14 @@ void IOSStabilityMetricsProvider::ProvideInitialStabilityMetrics(
     return;
   }
 
+  // If this is the first launch after an upgrade, existing crash reports
+  // may have been deleted before this code runs, so log this case in its
+  // own bucket.
+  if (IsFirstLaunchAfterUpgrade()) {

[stuartmorgan, 2015/07/21 20:16:24]

I realized after suggesting just flipping these that I'm not 100% certain
WasLashShutdownClean is still correct after an upgrade. Have you checked that
the first-new-lauch logic doesn't disturb this state?

[lpromero, 2015/07/21 22:12:07]

That's indeed to be checked. I will check that tomorrow.
IIRC, WasLastShutdownClean only reads a pref and I don't recall any special
treatment of this pref after an upgrade. We need to be sure.

BTW, Olivier raised the issue that this bucket is actually not necessary
anymore. It was there when logging the MobileSessionShutdownType was performed
in the main_controller, at the end of the startup sequence.
Now that MobileSessionShutdownType is correctly attributed to the correct
version (being in the initial stability log and not an ongoing log), we may not
need to account for this case.

[Olivier, 2015/07/22 16:54:19]

If the WasLastShutdownClean is not reliable after an upgrade, we need to keep
the bucket like it was (include both foreground and background).

If it is reliable, this bucket was introduced to avoid attributing crashes from
previous version to the new version.
We just ignored the previous version shutdown, in the stats and that's it.
Now that the version of the histogram is correct, we could just consider the
shutdown as a normal one.

[stuartmorgan, 2015/07/28 22:27:43]

The comment for this block is still true AFAICT. MainController has:
  // Cleanup crash reports if this is the first run after an update.
  if (isFirstLaunchAfterUpgrade_) {
    [self scheduleCrashReportCleanup];
  }
So it seems like it's still the case that on first launch, the information we
have is different, and if we remove this state entirely then we'll incorrectly
put some crashes with logs into the no-log buckets. This is orthogonal to
WasLastShutdownClean being reliable.

[Olivier, 2015/07/29 08:01:27]

 Even if we clean the reports, we can keep track that there were reports at
startup.

+    LogShutdownType(SHUTDOWN_IN_FOREGROUND_UNKNOWN_LOG_STATE);
+    return;
+  }
+
   // If the last app lifetime ended in a crash, log the type of crash.
   MobileSessionShutdownType shutdown_type;
   const bool with_crash_log =