wifi: ensure APs remain in scan list when supplicant updates them
The port to the new supplicant D-Bus API for NM 0.9 had one unfinished piece, which was to remove old APs from the scan list when the supplicant returned no scan results or there was a scan error. In this case, the removal code would not be called. This wasn't much of a problem until 836f7d17 which began removing APs from the scan list correctly in this case. This uncovered a bug in NM's wpa_supplicant management code, which was that NM only updates its internal AP object 'last seen' timestamp when the AP is reported by the supplicant as a completely new BSS (in merge_scanned_ap()). But the new supplicant D-Bus interface only reports the BSS as "new" when the supplicant doesn't know about the BSS, either because it is a new BSS or because it's been removed from the supplicant's scan list at some point in the past. Thus for BSSes that are consistently kept in the supplicant's scan list, because the wifi driver is actually doing its job and reporting them consistently in scan results, NM would not be updating the 'last seen' value for the corresponding NM AP objects. Due to 836f7d17 this would cause APs that should be kept to be removed from the NM scan list. To fix this, have the NMAccessPoint object track which supplicant dbus object it came from, and have NMSupplicantInterface listen for PropertyChanged signals for those APs the supplicant knows about. When something changes (like signal strength as the result of updated scan results) update the AP's 'last seen' timestamp since it clearly still exists in the scan list. This way we update the timestamp both when the supplicant finds a new AP and when it updates the properties of existing APs.
Showing with 220 additions and 46 deletions