Refactor WebRTC getUserMedia tests to be more explicit and clear.

Refactor WebRTC getUserMedia tests to be more explicit and clear.

This patch fixes a bunch of ambigous names, inlines a bunch of
unnecessary helper methods and gets rid of the magical global variable
gLocalStream.

In general, the first acquired stream had a first-class citizen status
that made tests with several streams very confusing. It was also
assumed to go together with the video tag local-view-1. This is still
true, but it has been made much more explicit in the code.

The tracing test still needs a "global", but I worked around that
problem by 1) letting the c++ code be in control of what that global
is and 2) stashing in in window[streamName] so it doesn't pollute the
rest of js code, which does not need this variable to be global.

The next step is to try to make the *TwoGetUserMedia* tests be more
parallel, or at least do less checks. They're too slow on Windows,
which causes them to flake.

BUG=417756
Committed: https://crrev.com/4eb7545566f51c7e48ddd1b672520514d795a17b
Cr-Commit-Position: refs/heads/master@{#298484}

[phoglund_chromium, 2014-10-07 12:16:10]

phoglund@chromium.org changed reviewers:
+ perkj@chromium.org

[perkj_chrome, 2014-10-07 13:07:23]

lgtm - but please consider rewording your TODO

https://codereview.chromium.org/635833002/diff/20001/content/test/data/media/...
File content/test/data/media/getusermedia.html (right):

https://codereview.chromium.org/635833002/diff/20001/content/test/data/media/...
content/test/data/media/getusermedia.html:168: // TODO(phoglund): make gUM
requests in parallel; this test is too slow
its not the actual request that is slow right? It must be rendering in two
players and detecting video?

[phoglund_chromium, 2014-10-07 13:57:53]

https://codereview.chromium.org/635833002/diff/20001/content/test/data/media/...
File content/test/data/media/getusermedia.html (right):

https://codereview.chromium.org/635833002/diff/20001/content/test/data/media/...
content/test/data/media/getusermedia.html:168: // TODO(phoglund): make gUM
requests in parallel; this test is too slow
On 2014/10/07 13:07:23, perkj wrote:
> its not the actual request that is slow right? It must be rendering in two
> players and detecting video?
No, I mean that the cycle of detect - gum - detect - gum - stop - detect - stop
- detect contains too many detection phases. On bots with GPU emulation this
looks to be really slow, so I was thinking we could at least get video up for
both streams simultaneously and thereby run the first two detects in parallel. I
can reword the TODO to be more clear.

[phoglund_chromium, 2014-10-07 13:58:06]

The CQ bit was checked by phoglund@chromium.org

[commit-bot: I haz the power, 2014-10-07 13:59:21]

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

[commit-bot: I haz the power, 2014-10-07 15:34:17]

Committed patchset #3 (id:40001) as d54042c35d68e05bec0f590e9fa1a7354a636b65

[commit-bot: I haz the power, 2014-10-07 15:35:01]

Patchset 3 (id:??) landed as
https://crrev.com/4eb7545566f51c7e48ddd1b672520514d795a17b
Cr-Commit-Position: refs/heads/master@{#298484}