Adapt Chrome to use KeystoneRegistration 1.0.7.1306

Adapt Chrome to use KeystoneRegistration 1.0.7.1306.  Use "tag path" and "tag
key" to direct Keystone to use a tag stored in the application as opposed to
in its ticket.

BUG=30730
TEST= - ksadmin --print-ticket --productid com.google.Chrome should show
        tagPath pointing to GC.app/Contents/Info.plist, and
        tagKey of KSChannelID;
      - ksadmin --print-tag --productid com.google.Chrome should show the
        value of the KSChannelID key in GC.app/Contents/Info.plist;
        this should be the tag that is used for auto-updates
     The above steps should be validated after the following operations:
      - launching Chrome when on a user ticket,
      - promoting Chrome from a user ticket to a system ticket, and
      - when a Chrome update is applied (using this version of
        keystone_install.sh) when on either a user or a system ticket.
     The tagPath and tagKey will NOT be set when launching Chrome on a
     system (promoted) ticket, but they WILL be set when the ticket is
     initially promoted and also when an update is applied using this version
     of keystone_install.sh.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=35030

[Mark Mentovai, 2009-12-17 22:12:22]

I'm still setting the tag directly in the ticket using ksadmin --tag (in
keystone_install.sh) and by providing a value for KSRegistrationTagKey (in
keystone_glue.mm).  This tag should no longer be used Keystone 1.0.7.1306 or
newer is available.  I'm still setting the tag values in the ticket defensively
in case there's a version mismatch between the registration framework and the
installed Keystone.

[Mark Mentovai, 2009-12-17 22:13:00]

Note to self: don't check this in without bringing in the newer Keystone
version.  I'm awaiting QA validation before taking that step.

[John Grabowski, 2009-12-17 22:26:32]

LGTM

http://codereview.chromium.org/506061/diff/1/4
File chrome/tools/build/mac/keystone_install.sh (right):

http://codereview.chromium.org/506061/diff/1/4#newcode351
chrome/tools/build/mac/keystone_install.sh:351: if [ ${KSADMIN_VERSION_MAJOR}
-gt 1 ] ||
perhaps add helper function called does_keystone_understand_tag_path which does
the version check stuff.  Also possibly use different exit codes for each of the
3 uses of 11 so we can tell the difference.

[TVL, 2009-12-18 03:23:56]

http://codereview.chromium.org/506061/diff/1/2
File chrome/browser/cocoa/keystone_glue.mm (right):

http://codereview.chromium.org/506061/diff/1/2#newcode152
chrome/browser/cocoa/keystone_glue.mm:152: const NSString* const
kAutoupdateStatusVersion = @"version";
why not namespace these also?

[Mark Mentovai, 2009-12-18 03:27:37]

http://codereview.chromium.org/506061/diff/1/2
File chrome/browser/cocoa/keystone_glue.mm (right):

http://codereview.chromium.org/506061/diff/1/2#newcode152
chrome/browser/cocoa/keystone_glue.mm:152: const NSString* const
kAutoupdateStatusVersion = @"version";
TVL wrote:
> why not namespace these also?

These need to be exposed to the About window controller.

[Mark Dalrymple, 2009-12-18 14:30:33]

Looks good to me.

[Mark Mentovai, 2009-12-18 19:59:20]

I refactored the version-check and feature-check stuff into some handy
functions.

I left the "11" exit codes alone because these ksadmin invocations really all do
the same thing.  In fact, I almost consolidated them into one call whose
arguments come from an array that has its elements set based on the presence of
the features, but I decided to hold off on that to keep this change simpler.