Services are not invalidated when BLE peripheral disconnects

When there is a connection with a Bluetooth Low Energy peripheral and the connection is closed by the peripheral (due to a power cycle or it gets out of range), the created and discovered services are not invalidated (using the InvalidateServices call) under iOS, OSX and Android.

What happens under iOS and OSX is that on disconnection, the QLowEnergyControllerPrivateOSX administration (discoveredServices) remains and services remain in there current state (for example ServiceDiscovered). When the application reconnects to the peripheral later and performs a service discovery, services that are found and that are still in discoveredServices are not recreated. So when the application tries to perform a detailed discovery, nothing happens because the service state is still ServiceDiscovered, and the handle administration is not updated. When the application then tries to write to a characteristic or descriptor, an error is given in the central manager that the handle is not in charMap or in descMap.

For Android, the situation is a little better, because there the services are always recreated when a service discovery is performed so when the service is created again in the application (using createServiceObject), the detailed discovery does perform a new discovery and everything is OK.
However, exisiting service objects are not set to the InvalidService state so there is also no signal to the application that the service is no longer available and when a service is no longer offered by a peripheral after reconnecting, it is still returned when QLowEnergyController::services is called (with a status not being InvalidService).

This can be solved under iOS / OSX by calling invalidateServices in the QLowEnergyControllerPrivateOSX::disconnected method.
Under android, this can be solved by calling invalidateServices in the QLowEnergyControllerPrivate::connectionUpdated function.