Refactor SetOmahaExperimentLabel out of gcpai and into install_util.

chrome/installer/util/google_chrome_sxs_distribution.cc

Index: chrome/installer/util/google_chrome_sxs_distribution.cc
diff --git a/chrome/installer/util/google_chrome_sxs_distribution.cc b/chrome/installer/util/google_chrome_sxs_distribution.cc
index 157fd74be4280ada3e60e0eef1f9e4c1779ff495..f6181ebeb44bc29cf0e8f89987d8c915de169d49 100644
--- a/chrome/installer/util/google_chrome_sxs_distribution.cc
+++ b/chrome/installer/util/google_chrome_sxs_distribution.cc
@@ -71,6 +71,10 @@ 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;
 }