[Telemetry] Change TracingBackend.Stop to return the trace data from last tracing run.

Change TracingBackend.Stop to return the trace data from last tracing run.

The bug 421097 was caused by the refactoring to disable trace
nesting call feature. Since trace-profiler makes the call to
StartTracing earlier than measurement and makes the call top
StopTracing after measurement has called StopTracing, it
raises TracingNotRunningException().

This fixes the bug by modifying the behavior of
StopTracing() slightly to return the trace data of the last
run. Note that trace-profiler  itself does not provide a
good way to get useful trace data (the measurement uses
tracing with different overhead level without knowing it).
The long term fix should be moving all trace-based
measurement to timeline_based_measurement.

BUG=421097
Committed: https://crrev.com/48f92772739028b8bc5bca9302e0d51dd6fa9097
Cr-Commit-Position: refs/heads/master@{#298992}

[nednguyen, 2014-10-09 18:06:09]

nednguyen@google.com changed reviewers:
+ ernstm@chromium.org, skyostil@google.com

[nednguyen, 2014-10-09 18:14:23]

nednguyen@google.com changed reviewers:
+ dtu@chromium.org

[ernstm, 2014-10-09 21:58:50]

On 2014/10/09 18:06:09, nednguyen wrote:

For smoothness with profiler=trace we would:
profiler: StartTracing with default categories
measurement: StartTraing with min overhead, but the call returns immediately
measurement: StopTracing and get trace with default categories since profiler
started
profiler: StopTracing and get the same trace from the previous step.

Is that correct?

[nednguyen, 2014-10-09 22:04:41]

On 2014/10/09 21:58:50, ernstm wrote:
> On 2014/10/09 18:06:09, nednguyen wrote:
> 
> For smoothness with profiler=trace we would:
> profiler: StartTracing with default categories
> measurement: StartTraing with min overhead, but the call returns immediately
> measurement: StopTracing and get trace with default categories since profiler
> started
> profiler: StopTracing and get the same trace from the previous step.
> 
> Is that correct?

Yes, it's correct.

[ernstm, 2014-10-09 22:06:32]

On 2014/10/09 22:04:41, nednguyen wrote:
> On 2014/10/09 21:58:50, ernstm wrote:
> > On 2014/10/09 18:06:09, nednguyen wrote:
> > 
> > For smoothness with profiler=trace we would:
> > profiler: StartTracing with default categories
> > measurement: StartTraing with min overhead, but the call returns immediately
> > measurement: StopTracing and get trace with default categories since
profiler
> > started
> > profiler: StopTracing and get the same trace from the previous step.
> > 
> > Is that correct?
> 
> Yes, it's correct.

LGTM

[nednguyen, 2014-10-09 22:07:26]

The CQ bit was checked by nednguyen@google.com

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

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

[commit-bot: I haz the power, 2014-10-09 22:20:59]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-10-09 22:22:24]

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