Add log date to the metrics log

components/metrics/proto/system_profile.proto

Index: components/metrics/proto/system_profile.proto
diff --git a/components/metrics/proto/system_profile.proto b/components/metrics/proto/system_profile.proto
index c116a0a1d1909830675f3e6b3442cae3924b56d0..041c9d4539e083ad66c3d66e4bd4f4469a56861c 100644
--- a/components/metrics/proto/system_profile.proto
+++ b/components/metrics/proto/system_profile.proto
@@ -13,7 +13,7 @@ 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;
@@ -860,4 +860,7 @@ message SystemProfileProto {
     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.

 }