backends/bluezdbus/manager: Cancel the discovery on disconnect to avoid a timeout

[arthur-proglove]

If a device disconnects while waiting for the services to be discovered, the manager will wait forever.
This commit fixes that by introducing a context to the _wait_condition method with an exception on disconnect.

[dlech]

I agree this should be fixed, but I would like to suggest a different way of doing it. Instead of introducing a new class, we should be able to use asyncio.wait(..., return_when=FIRST_COMPLETED) to wait for either ServicesResolved==True or "Connected"==False. If the latter wins the race, raise an exception.

[arthur-proglove]

I agree this should be fixed, but I would like to suggest a different way of doing it. Instead of introducing a new class, we should be able to use asyncio.wait(..., return_when=FIRST_COMPLETED) to wait for either ServicesResolved==True or "Connected"==False. If the latter wins the race, raise an exception.

Oh, thank you for highlighting this function, I only knew gather.

I tried to make something prettier than accessing directly self._properties[device_path][defs.DEVICE_INTERFACE]["Connected"] in the callback but could not find something more elegant. Using the device watcher callbacks seemed overkill.

[dlech]

Good start. However, _wait_condition is a generic function, so we should leave it that way.

The asyncio.wait() logic looks right, but it should replace await self._wait_condition(device_path, "ServicesResolved", True) in get_services(). And the two tasks can be defined at self._wait_condition(device_path, "ServicesResolved", True) and self._wait_condition(device_path, "Connected", False).

[arthur-proglove]

Right! I was so focused on my services discovery issue that I completely skipped the fact that this method is for any property change.

[dlech]

Looks great, thanks!