Telemetry, Mac: Use the actual keychain for performance tests.

Telemetry, Mac: Use the actual keychain for performance tests.

The real keychain was stubbed out because it was causing problems
with page cyclers on 10.9 perf bots.
https://codereview.chromium.org/176583002

This is problematic because it prevents us from catching real performance
regressions involving the keychain.
https://code.google.com/p/chromium/issues/detail?id=397308

Rather than disabling keychain interactions altogether, we should fix the 10.9
page cycler problems. I added a wiki page describing the correct configuration
for the keychain on Macs.
https://sites.google.com/a/chromium.org/dev/developers/telemetry/telemetry-mac-keychain-setup

This change will cause a serious performance regression for the telemetry test
session_restore, and possibly others, since Chrome does not interact well with
the keychain. See the associated bug. Note that this regression reflects
accurate user conditions, and that the current performance statistics are
artifically lowered by stubbing out keychain interactions.

BUG=397308
Committed: https://crrev.com/e38f0dad2e9bdccfaa900e9c2bda2a6e61d85c8b
Cr-Commit-Position: refs/heads/master@{#302917}

[erikchen, 2014-07-25 00:58:47]

tonyg: Please review.

This change is likely going to cause problems with the 10.9 bots with regards to
page cycling, since that is why keychain interactions were turned off to begin
with. If I can get access to the bots, I will configure their keychains so that
there won't be problems.

(Given that the problem was specifically with page cyclers, it was probably
caused by https://code.google.com/p/chromium/issues/detail?id=178358. That is no
longer a problem on top of tree.

[tonyg, 2014-07-25 01:12:15]

[+oysteine, current perf sheriff]

We can't land this if it is going to cause the timeouts again. However, we can
land it if it only causes fake perf regressions.

If you suspect those steps are necessary on the bots, then please file a bug
with the label Chrome-Labs asking them to fix that *before* this lands.

Just curious why you decided against the alternate approach we talked about of
changing the flag behavior?

In any case here's an lgtm if you just want to try this, but just be forewarned
it'll get reverted if anything times out.

[erikchen, 2014-07-25 01:27:58]

Two reasons:

1. I was mistaken about telemetry being the only user of the mock keychain. In
process browser tests and unit tests both use that flag.

2. While it is possible for us to prevent keychain accesses that would cause
prompts, it also prevents us from testing all the standard keychain logic. The
behavior will be different, both from a functional and a performance
perspective. If indeed the 10.9 machines are misconfigured, and Chromium can't
access the keychain properly, then the performance bug listed in this CL's
description would not have been caught by the 10.9 machines.

[tonyg, 2014-07-25 01:38:23]

On 2014/07/25 01:27:58, erikchen wrote:
> Two reasons:
> 
> 1. I was mistaken about telemetry being the only user of the mock keychain. In
> process browser tests and unit tests both use that flag.
> 
> 2. While it is possible for us to prevent keychain accesses that would cause
> prompts, it also prevents us from testing all the standard keychain logic. The
> behavior will be different, both from a functional and a performance
> perspective. If indeed the 10.9 machines are misconfigured, and Chromium can't
> access the keychain properly, then the performance bug listed in this CL's
> description would not have been caught by the 10.9 machines.

Got it. Thanks for the explanation.

[erikchen, 2014-11-05 17:32:57]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2014-11-05 17:34:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/419133002/1

[commit-bot: I haz the power, 2014-11-05 19:20:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-11-05 19:20:36]

Try jobs failed on following builders:
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)

[erikchen, 2014-11-05 19:23:08]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2014-11-05 19:24:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/419133002/1

[commit-bot: I haz the power, 2014-11-05 21:23:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-11-05 21:23:39]

Try jobs failed on following builders:
  android_dbg_tests_recipe on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_dbg_tes...)

[erikchen, 2014-11-05 21:25:23]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2014-11-05 21:26:35]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/419133002/1

[commit-bot: I haz the power, 2014-11-06 00:23:43]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-11-06 00:24:30]

Patchset 1 (id:??) landed as
https://crrev.com/e38f0dad2e9bdccfaa900e9c2bda2a6e61d85c8b
Cr-Commit-Position: refs/heads/master@{#302917}

[erikchen, 2014-11-06 18:55:51]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/681113009/ by erikchen@chromium.org.

The reason for reverting is: Bots need to have their configs updated before this
CL can land..