Add process lifetime annotations to stack samples.

components/metrics/proto/execution_context.proto

Index: components/metrics/proto/execution_context.proto
diff --git a/components/metrics/proto/execution_context.proto b/components/metrics/proto/execution_context.proto
index 3d8679fe9db2bd8ce69660940c35c7f2416e434a..9076a3d62f39acdd5c0bcbae2ef1b1888d2f9cda 100644
--- a/components/metrics/proto/execution_context.proto
+++ b/components/metrics/proto/execution_context.proto
@@ -47,3 +47,18 @@ enum Thread {
   RENDER_THREAD = 9;
   UTILITY_THREAD = 10;
 }
+
+// Process phases, or where in the lifetime of the process it is such as
+// startup, normal operation, shutdown, etc. These don't necessarily occur in
+// the order defined here so it's fine to add new ones to further segregrate
+// the lifetime of a process.
+enum ProcessPhase {
+  MAIN_LOOP_STARTED = 0;
+  FIRST_NON_EMPTY_PAINT = 1;
+}
+
+// Process activities. These are actions that start and end, likely many
+// times, throughout the lifetime of a process.
+enum ProcessActivity {
+  METRICS_COLLECTION = 0;

[Mike Wittman, 2016/11/02 21:44:04]

What's the rationale beyond recording metrics collection as a phase?

[bcwhite, 2016/11/03 18:29:50]

It's not a phase, just a periodic activity that occurs (begins and ends) during
normal operation.  It's not yet used and so could change if it's not useful but
there has to be at least one value defined for tests not to break.

[Mike Wittman, 2016/11/03 21:15:39]

Sorry, "phase" was a typo. So, three things:

1. Proto changes have to be reviewed in google3 by internal logging and privacy
teams, and committed before they can be approved for commit in the Chrome
repository.

2. There's a substantial cost to changing these enums, both in terms of
re-review and backwards compatibility. Once sent over the wire the enum values
essentially have to live forever so the data can continue to be interpreted
server-side.

3. As a result, we should settle on exactly what these enums need to contain to
support recording the desired startup information, and get that reviewed in
google3 before committing here. If we don't have a need for recording process
activity yet then it should be removed for the time being.

[bcwhite, 2016/11/03 21:51:10]

Ah, well then.  I had planned to get this in, then the follow-on CL, all before
going the google3 version.  Since nothing yet sets those bits, they could be
changed to whatever with no backward compatibility problems.

I guess there will have to be some discussion next week.

[Mike Wittman, 2016/11/03 23:11:03]

In general we shouldn't be committing Chrome functionality to support uploading
new state -- even if incomplete or disabled -- until we have policy approval for
saving the state. There are too many things that could go wrong (e.g. random bit
flips) that could cause state to be uploaded anyway and put us in questionable
territory. Google3 approval for this stuff, once settled, shouldn't be difficult
or take very long.

Let's move discussions of which startup phases should be recorded into the bug.

I won't be there for discussions next week, but I'm sure Alexei can provide
guidance.

[bcwhite, 2016/11/04 14:03:45]

Makes perfect sense.  I just didn't know about it.

+}