Add process lifetime annotations to stack samples.

components/metrics/proto/call_stack_profile.proto

Index: components/metrics/proto/call_stack_profile.proto
diff --git a/components/metrics/proto/call_stack_profile.proto b/components/metrics/proto/call_stack_profile.proto
index e41b3390224ab8561f2285d7bd36217d990475ef..06253e2696481de0e2e6fb48d773c60504a51c0d 100644
--- a/components/metrics/proto/call_stack_profile.proto
+++ b/components/metrics/proto/call_stack_profile.proto
@@ -32,6 +32,17 @@ message CallStackProfile {
 
     // Number of times this stack signature occurs.
     optional int64 count = 2;
+
+    // This bit-field provide information about the current phase of the system
+    // such as whether it is in startup, general operation, or shutdown. This
+    // field is not present if it is unchanged from the previous Sample.
+    optional fixed32 process_phases = 3;

[Mike Wittman, 2016/10/24 22:28:14]

The individual phases and activities should be explicitly specified in the
proto, so we have agreement on meaning between the Chrome side and and the
server side.

My understanding is that it's not practical to define bitmask constants in
protos, and the standard way of representing data like this is fields of
repeated enums (as mentioned by Alexei in the bug). We'll need to translate
between the two representations in the metrics provider.

[bcwhite, 2016/10/25 14:45:23]

As I understand it, this will require the constants to be defined in at least
three places:

stack_sampling_profiler.h (in Chrome)
call_stack_profiles.proto (in Chrome)
call_stack_profile.proto (in Google3)
(another in Google3?)

Wouldn't it be better to _not_ define it in the .proto at all and define it only
twice:

stack_sampling_profiler.h (in Chrome)
stack_sampling_profiler.h (or whatever it's called -- in Google3)

[Mike Wittman, 2016/10/25 17:24:22]

The interpretation of the phases/activities is part of the interface between
Chrome and the UMA server, so it really should be explicitly specified. Without
it there's no good mechanism to manage changes to the data being sent/processed
across versions of Chrome and the server code. The duplication is unfortunately
unavoidable, but as far as I know doing things this way is standard practice.

If the enums are in a standalone proto -- execution_context.proto probably would
be a good home -- then the constants will be defined in two places, one of which
gets copied to Google3. The Google3 stack_sampling_profiler.h equivalent is a
proto definition rather than anything defined in source code, so there's no
additional duplication there.

[bcwhite, 2016/10/25 21:10:42]

I'll work on it.

+
+    // This bit-field provide information about current activities of the system
+    // such as whether it is (for example) writing out profile information or
+    // uploading metrics. This field is not present if it is unchanged from the
+    // previous Sample.
+    optional fixed32 current_activities = 4;
   }
 
   // Uniquely identifies a module.