Provide FrameTiming flush mechanism

[liyuqian]

Currently, multiple FrameTimings are batched by the engine so it's hard for the framework to precisely control when to start and stop FrameTiming monitoring. That could make the benchmark either count some old frames before the profiling that it shouldn't count, or miss some frames in the end of profiling. (#64780 is a workaround to mitigate this.)

We should add an API to let the framework instruct the engine to reliably flush all pending FrameTimings to solve this issue.

[chinmaygarde]

It seem like the ask here is to discard old traces before starting collection anew. If this is possible at all (AFAIK, there are thread specific trace buffers and there may not be a way to clear all of them at a specific time), we will need a Dart VM API to do this. The timeline mechanism may not tool for getting real time trace information from the VM. CC @rmacnak-google for thoughts on this.

[chinmaygarde]

Elevating priority on this as fixing this should go a long way towards making benchmarks less flaky.

[liyuqian]

The batching here doesn't involve Dart VM Timeline so I hope it can be done just in the engine.

[rmacnak-google]

If the VM is configured to buffer the timeline events itself instead of forwarding them to the system tracer, it is possible to clear this buffer with clearVMTimeline. This should include thread-local buffers.

Though if a benchmark wants to compute its score by examining the timeline, I would recommend emitting events that show the scope of the benchmark and filtering based on the timestamps of those events rather than clearing the timeline itself. Clearing would remove context useful when someone manually investigates the benchmark, and clearing only works for discarding events that are too early and not for events that are too late.

[kf6gpe]

As this is a new feature request, reprioritizing to reflect our current triage priorities.