This allows us to ignore all the delays when the device is emulated, with the
idea being to do dozens of device emulations in the CI tests.
Also, do not call fu_progress_sleep() when the device is emulated.
We're not going to subclass this, and making it final saves during startup:
* 300K calls of fu_progress_get_instance_private()
* 280K calls of fu_progress_get_step_weighting()
Using `sudo FWUPD_PROFILE=10 ./src/fwupd --verbose` will print a
dump of startup times onto the console so that we can debug which
plugin is slowing down system startup. For example:
../src/fu-engine.c:5409:plugins-coldplug [108.55ms]:
../plugins/amt/fu-plugin-amt.c:437:amt [27.14ms]:
:create-context [12.66ms]
:get-version [8.44ms]
:add-device [3.95ms]
This allows us to print better warning strings, and in the future
would allow us to profile each operation in a meaningful way.
Also, add context to some of the progress steps as required.
When the child has completed we rely on the next fu_progress_step_done()
call to set the status value back to the parent-defined value. In the
case where there is a delay until the next step is done (e.g. waiting
for hardware to re-enumerate) the child status persisted incorrectly.
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
