Refactor SetOmahaExperimentLabel out of gcpai and into install_util.

chrome/installer/util/google_chrome_sxs_distribution.cc

 // Copyright (c) 2012 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.
 //
 // This file defines implementation of GoogleChromeSxSDistribution.
 
 #include "chrome/installer/util/google_chrome_sxs_distribution.h"
 
 #include "base/command_line.h"
 #include "base/logging.h"
@@ skipping 53 matching lines @@
 
 bool GoogleChromeSxSDistribution::GetCommandExecuteImplClsid(
     string16* handler_class_uuid) {
   return false;
 }
 
 bool GoogleChromeSxSDistribution::AppHostIsSupported() {
   return false;
 }
 
+bool GoogleChromeSxSDistribution::ShouldWriteExperimentLabels() const {
+  return true;

[grt (UTC plus 2), 2012/11/24 02:58:37]

Note: GCAPI doesn't have facilities for changing the labels for canary. I'd
expected to see "false" here as a result. If canary really should be writing the
labels, then you can remove this override since the SxS class extends the
GoogleChrome class.

[SteveT, 2012/11/26 20:45:06]

Hmm, well I guess this "ShouldWriteExperimentLabels" semantically refers to
whether or not we should write them for FieldTrials for Chrome... not
necessarily whether or not we should write them for GCAPI.

Should GCAPI be doing this for Chrome Frame installs (writing their
brand_whatever entry in experiment_labels)? If so, we have to change this logic
around a bit..

[grt (UTC plus 2), 2012/11/26 21:19:05]

What I meant was that the original GCAPI code didn't write the reactivation
label for canary (because GCAPI only does a "reactivation" for Google Chrome).
I don't think so.  GCAPI is for Google Chrome, not canary or Chrome Frame.

+}
+
 string16 GoogleChromeSxSDistribution::ChannelName() {
   return kChannelName;
 }