Add ScopedKeepAlive to c/b/lifetime

chrome/browser/lifetime/keep_alive_options.h

Index: chrome/browser/lifetime/keep_alive_options.h
diff --git a/chrome/browser/lifetime/keep_alive_options.h b/chrome/browser/lifetime/keep_alive_options.h
new file mode 100644
index 0000000000000000000000000000000000000000..8918912e6a0435505fa81e1841e834af42fe7b45
--- /dev/null
+++ b/chrome/browser/lifetime/keep_alive_options.h
@@ -0,0 +1,20 @@
+// Copyright 2016 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.
+
+#ifndef CHROME_BROWSER_LIFETIME_KEEP_ALIVE_OPTIONS_H_
+#define CHROME_BROWSER_LIFETIME_KEEP_ALIVE_OPTIONS_H_
+
+struct KeepAliveOptions {
+  // Should be descriptive of what the KeepAlive's lifetime is tied to, to help
+  // with debugging.
+  const char* label;

[sky, 2016/02/22 21:26:05]

Can you explain why a string is better than an enum here? An enum provides the
context and is much easier in the call sites.

[dgn, 2016/02/23 12:58:06]

The idea was that each call site would use a descriptive string, that would give
some information about the purpose of that KeepAlive. Those strings can be
displayed for debug purposes, and for example could be shown in an about://
page. 

Having one enum per call site would require maintaining a centralized list, and
have c/b/lifetime be aware of all the call sites, which I think would be
strange. Also, we would still have to add the string mappings that go with that
list for debugging.

From the Release point of view, enums have their advantages. I don't feel
strongly about that, I can change it if you want.

+
+  // TODO(dgn)
+  // When registering a token, we should add indications of which kind of
+  // optimizations are allowed during the KeepAlive's lifetime. This will allow
+  // to have more info about the state of the browser to optimize the resource
+  // consumption.
+};
+
+#endif  // CHROME_BROWSER_LIFETIME_KEEP_ALIVE_OPTIONS_H_