If --gdb is used with test-runner, all the timeouts in the
IWD class must be turned off otherwise the test will fail.
Inside test-runner, a environment variable (IWD_TEST_TIMEOUTS)
is set to either 'on' or 'off'. Then the IWD class (and any
others) can handle the timeouts accordingly. Note that this
does not turn off dbus timeouts, rather it ignores timeout
failures. This does mean that ultimately the test will most
likely fail due to a dbus timeout, but it at least gives you
unlimited debugging time.
We need to reset self._exception after _wait_for_async_op raises an
exception, otherwise _wait_for_async_op will report that exception for
every future operation (this wasn't an issue when an exception always
meant that the test was failing and objects were torn down anyway)
Sometimes iwd will take a while to register its dbus name. The python
class already waits for the name to appear on dbus if iwd is being
launched from python, do this also if iwd was already launched by the
test-runner. My use case was when running iwd under valgrind in which
case it runs slower.
Modify AsyncOpAbstract._wait_for_async_op and
IWD.wait_for_object_condition to call context.iteration() in the
blocking mode instead of calling context.pending() every 0.01s. This
gets rid of busy-waiting and also ensures that the condition is checked
after every single dbus (or other) event. This way a condition that
potentially occurs for less than 0.01s can be reliably waited for.
