access denied error in windows backend due to GattServicesChanged event

[dlech]

I had a very similar problem while writing data to a Nordic UART service. I had many access denies errors when I started with bleak version 0.13 and after updating to 0.15 it change more to "The object is already closed" or "A method was called at an unexpected time" (don't know the exact error messages as my system reported them in German)
The problem for me was that the device kept updating the service list during service discovery. I added a gatt_services_changed listener to the WinRT client and started over with service discovery if it is was currently running or started a new discovery before accessing the services list the next time.
The documentation of the GattServicesChanged event (https://docs.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.bluetoothledevice.gattserviceschanged) says:

This event is raised when the remote device changes its services, or an unpaired device is disconnecting. All services are cleared because unpaired device services can't be cached between connections.
The object parameter in this event is null for every event that is raised.
In your handler for this event, do the following in order to get the services available. Call BluetoothLEDevice.GetGattServicesAsync on the BluetoothLEDevice that's passed to your handler. When calling GetGattServicesAsync, use the Cached option. This can be used to refresh the list of services and re-initialize the services on the device if they are gone.

For my device I get the event 11 times during the first service discovery and if I reload them after I got the event everything works as expected.
I can open a PR in the next days with a suggestion how to deal with this issue.

Originally posted by @jochenjagers in #849 (comment)

[dlech]

This seems like a tricky one to handle. We can't know if a device has a Services Changed characteristic until services have been resolved. And we can't know when Windows decides to enable indications on this characteristic. If we get the event during get_services(), then we can cancel the GetGattServicesAsync call and try again. But we don't currently have a nice way to handle this if we get the signal after get_services() returns.