Await for the gecko profiler start instead of adding a synthetic delay

[canova]

Feature/improvement

Currently browsertime adds a delay after the gecko profiler start command: https://github.com/sitespeedio/browsertime/blob/79e9b0e1f72c3005641b1131173cdaaf24f93a51/lib/firefox/geckoProfiler.js#L89-L90 This was because previously we didn't have a way to properly await for the profiler start since all the processes start the profiler individually. But this year, with the Bug 1668867, we've started to return a Promise instead from the Services.profiler.StartProfiler API and it resolves when all the processes start profiling. This way we can start the profiler and await until it's ready without needing an additional settle delay.

Here's the profiler start command in browsertime: https://github.com/sitespeedio/browsertime/blob/79e9b0e1f72c3005641b1131173cdaaf24f93a51/lib/firefox/geckoProfiler.js#L74-L77

Here's an example in our tests: https://searchfox.org/mozilla-central/rev/0a2eba79c24300ce0539f91c1bebac2e75264e58/tools/profiler/tests/xpcshell/test_active_configuration.js#24-30

[soulgalore]

Hi @canova ah cool, so then I can just remove the extra wait and it will work as it should right?

[canova]

Yes, it should work as expected without the extra wait if we properly await the Services.profiler.StartProfiler. Not sure if we are doing it already? I see an await in front of the runner.runPrivilegedScript call but there is no await inside the script that's passed to runPrivilegedScript as an argument. Probably it's not awaiting for that one?