DevTools: notify backend agents about profiler started/stopped events

DevTools: notify backend agents about profiler started/stopped events

This patch provides a way to notify backend agents about starting a profiler.
Each agent should switch to a mode which doesn't affect the performance.
As example DebuggerAgent needs to disable breakpoints, allow v8 optimizations, etc.
DOM and Network agents may simple disable themselves.

BUG=381115
R=pfeldman@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175946

[pfeldman, 2014-06-10 15:26:59]

lgtm

lets add that to timeline and tracing. Also, do we want to make it mutually
exclusive for them? i.e. add isProfiling there?

[loislo, 2014-06-10 15:30:33]

On 2014/06/10 15:26:59, pfeldman_ooo wrote:
> lgtm
> 
> lets add that to timeline and tracing. Also, do we want to make it mutually
> exclusive for them? i.e. add isProfiling there?

nope. We have an experiment which mixes Timeline with CPU profiler.

[vsevik, 2014-06-10 15:32:24]

On 2014/06/10 15:26:59, pfeldman_ooo wrote:
> lgtm
> 
> lets add that to timeline and tracing. Also, do we want to make it mutually
> exclusive for them? i.e. add isProfiling there?

We discussed this offline and my understanding is that e.g. TimelineAgent would
not affect performance per se, only if it is also started.
So front-end is in control of that and there is no much need to handle
profilingStarted calls in "performance agents".

[loislo, 2014-06-10 15:57:02]

On 2014/06/10 15:32:24, vsevik wrote:
> On 2014/06/10 15:26:59, pfeldman_ooo wrote:
> > lgtm
> > 
> > lets add that to timeline and tracing. Also, do we want to make it mutually
> > exclusive for them? i.e. add isProfiling there?
> 
> We discussed this offline and my understanding is that e.g. TimelineAgent
would
> not affect performance per se, only if it is also started.
> So front-end is in control of that and there is no much need to handle
> profilingStarted calls in "performance agents".

comments addressed

[loislo, 2014-06-10 15:57:04]

The CQ bit was checked by loislo@chromium.org

[commit-bot: I haz the power, 2014-06-10 15:58:09]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/loislo@chromium.org/321173002/20001

[commit-bot: I haz the power, 2014-06-10 17:39:02]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/11450)

[commit-bot: I haz the power, 2014-06-10 22:39:03]

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

[commit-bot: I haz the power, 2014-06-10 22:39:04]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/11462)

[loislo, 2014-06-11 06:18:11]

Committed patchset #2 manually as r175946 (presubmit successful).

[loislo, 2014-06-11 12:17:01]

A revert of this CL has been created in
https://codereview.chromium.org/327203002/ by loislo@chromium.org.

The reason for reverting is: We came to the conclusion that this patch
moves us in a wrong direction. 
With this approach we would have to manage 4 pairs of states. Disabled+stopped,
disabled+started, enabled+stopped, etc up to enabled+started :)
in the each agent. So we would like to try the simplest one, just use
enable/disable states and fix the problems related to them..

[pfeldman, 2014-06-25 04:52:14]

> The reason for reverting is: We came to the conclusion that this patch
> moves us in a wrong direction. 
> With this approach we would have to manage 4 pairs of states.
Disabled+stopped,
> disabled+started, enabled+stopped, etc up to enabled+started :)
> in the each agent. So we would like to try the simplest one, just use
> enable/disable states and fix the problems related to them..

I am not sure I understand the 4 pairs of states (8 in total?). As I see it, we
have 3 states in total:

- disabled
- enabled
- suspended

I still think this is the right way to proceed.