Add log date to the metrics log

components/metrics/proto/system_profile.proto

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 //
 // Stores information about the user's brower and system configuration.
 // The system configuration fields are recorded once per client session.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 option java_outer_classname = "SystemProfileProtos";
 option java_package = "org.chromium.components.metrics";
 
 package metrics;
 
-// Next tag: 24
+// Next tag: 25
 message SystemProfileProto {
   // The time when the client was compiled/linked, in seconds since the epoch.
   optional int64 build_timestamp = 1;
 
   // A version number string for the application.
   // Most commonly this is the browser version number found in a user agent
   // string, and is typically a 4-tuple of numbers separated by periods.  In
   // cases where the user agent version might be ambiguous (example: Linux 64-
   // bit build, rather than 32-bit build, or a Windows version used in some
   // special context, such as ChromeFrame running in IE), then this may include
@@ skipping 826 matching lines @@
     optional string product_version = 3;
 
     // The hash of the product version. Might not be set if the product version
     // could not be obtained from the disk.
     optional fixed32 product_version_hash = 4;
 
     // The current state of the product.
     optional AntiVirusState product_state = 5;
   }
   repeated AntiVirusProduct antivirus_product = 23;
+
+  // The time when the log was completed in seconds since the epoch.
+  optional int64 log_date = 24;

[Alexei Svitkine (slow), 2016/09/22 20:51:30]

So I wasn't thinking we include it in the actual log proto - but in the local
state storage of old logs that's managed by
components/metrics/persisted_logs.cc.

(The reason for that is that I think we never actually de-serialize the old logs
when loading them and sending them - we just read the data into
list_[i].compressed_log_data.)

So... to do it that way, probably the solution is to store this in prefs. Looks
like currently it stores it as a list and uses a strange convention of
alternating between storing hash and the data. We can either change this
structure to have 3 entries or switch to a new pref and use a dictionary as the
array element type. The latter seems more elegant to me, but we'd need the old
code for compatibility as well.

 }