Refactor SetOmahaExperimentLabel out of gcpai and into install_util.

chrome/installer/util/install_util.cc

Index: chrome/installer/util/install_util.cc
diff --git a/chrome/installer/util/install_util.cc b/chrome/installer/util/install_util.cc
index db710d47d9f85fb116098574e5d5bca6a9f4be7f..628e44af2e7b549148e468c86b19d18644b8ee7a 100644
--- a/chrome/installer/util/install_util.cc
+++ b/chrome/installer/util/install_util.cc
@@ -38,6 +38,13 @@ using installer::ProductState;
 
 namespace {
 
+const wchar_t* kExperimentAppGuids[] = {
+    L"{4DC8B4CA-1BDA-483e-B5FA-D3C12E15B62D}",
+    L"{8A69D345-D564-463C-AFF1-A69D9E530F96}",
+};
+
+const wchar_t kExperimentLabels[] = L"experiment_labels";
+
 const wchar_t kStageBinaryPatching[] = L"binary_patching";
 const wchar_t kStageBuilding[] = L"building";
 const wchar_t kStageConfiguringAutoLaunch[] = L"configuring_auto_launch";
@@ -523,6 +530,27 @@ string16 InstallUtil::GetCurrentDate() {
   return string16(date_str, len);
 }
 
+// static
+bool InstallUtil::SetOmahaExperimentLabel(const string16& experiment_label,

[grt (UTC plus 2), 2012/11/23 00:09:55]

If this is meant to be called from the context of chrome.exe, then it could
potentially be called for Chromium, Google Chrome, Google Chrome SxS (canaray),
Google Chrome Frame, or Google Chrome App Host (or possibly even setup.exe).
Cases like this are handled by the BrowserDistribution class -- the base class
handles the Chromium case, and various derived types handle all of the others. I
think the right thing to do here is to add something like:
  virtual bool HasExperiments();
to BrowserDistribution that returns false. Override this in
GoogleChromeDistribution (return true), GoogleChromeSxSDistribution (return
false), and GoogleChromeBinariesDistribution (return true).

Then in this function, assuming it is to be called from chrome.exe and GCAPI,
you do something like this:
  BrowserDistribution* dist = BrowserDistribution::GetDistribution();
  if (dist->HasExperiments()) {
    string16 client_state_path(dist->GetStateKey());
    RegKey client_state(root, client_state_root.c_str(), KEY_SET_VALUE);
    if (client_state.WriteValue(...) == ERROR_SUCCESS) { ... }
  }
This will only write to the registry for the products that actually have
experiments, and you get the correct registry location by going through the
GetStateKey method.

Since GCAPI is only meant to be used on Google Chrome, I think the call to
GetDistribution() will return the proper instance automatically.

If you need to preserve the behavior of writing into the key for the binaries (I
don't know why you would, but I haven't read any design docs so I'm completely
uninformed), then you'll furthermore need to do something like:

  if (InstallUtil::IsMultiInstall(dist, system_install)) {
    BrowserDistribution *binaries_dist =
BrowserDistribution::GetSpecificDistribution(BrowserDistribution::
CHROME_BINARIES);
    // do the same HasExperiments check such for binaries_dist
  }

Now come the extra twists. Have a drink while you read on. :-)

To handle the case of per-user vs. per-machine installs, the utility functions
in here typically take a |system_level| bool in param. Callers either already
know if they're user or system, or they use !InstallUtil::IsPerUserInstall(...)
to figure it out. This function should follow the same parameter, which means
replacing the HKEY registry_hive param with a bool system_level param, and then
inside the func have something like:
  HKEY root = system_level ? HKEY_LOCAL_MACHINE : HKEY_CURRENT_USER;

But wait, there's more!

System-level Chrome doesn't have permission to write to ClientState in HKLM.
Omaha creates a lower-rights key called ClientStateMedium for use in this case.
I've just looked at the corresponding Omaha code, and it does not appear to read
from ClientStateMedium, so you have a small problem here. You have two options:
have Omaha give priority to ClientStateMedium for per-machine installs (this is
how things like the EULA-accepted flag are handled), or use Omaha facilities to
launch setup.exe at high integrity and add special handling to setup.exe to set
this value. I think the former solution is easier, but it means that any
user-level process on a machine can potentially tweak the value. Maybe this
isn't a problem. If so, it's not a difficult thing to change Omaha's behavior.

+                                          HKEY registry_hive) {
+  size_t successful_writes = 0;
+  string16 experiment_path;
+  for (size_t i = 0; i < arraysize(kExperimentAppGuids); ++i) {
+    experiment_path = google_update::kRegPathClientState;
+    experiment_path += L"\\";
+    experiment_path += kExperimentAppGuids[i];
+
+    RegKey client_state(registry_hive, experiment_path.c_str(),
+                        KEY_SET_VALUE);
+    if (client_state.WriteValue(kExperimentLabels,
+                                experiment_label.c_str()) == ERROR_SUCCESS) {
+      ++successful_writes;
+    }
+  }
+
+  return (successful_writes == arraysize(kExperimentAppGuids));
+}
+
 // Open |path| with minimal access to obtain information about it, returning
 // true and populating |handle| on success.
 // static