supplicant: prevent a race condition due to D-Bus activation
interface_add() could get called from two places: by the wifi/eth device class when activating (which if the supplicant isn't yet running will D-Bus activate it) and from the NameOwnerChanged handler for the wpa_supplicant dbus service smgr_running_cb(). So if the supplicant wasn't running, nm_supplicant_interface_new() would call interface_add() to bring the supplicant to life via activation, then go on and create priv->iface_proxy. When the supplicant appeared and D-Bus sent the NameOwnerChanged, smgr_running_cb() would also call interface_add(), creating a second priv->iface_proxy. The first one got lost and lived after its parent NMSupplicantInterface was killed, and could still respond to signals over the bus. Prevent that by adding another state, STARTING, that indicates that we've already started talking to the supplicant. Also be extra paranoid about disconnecting signal handlers on the proxy.
Showing with 42 additions and 10 deletions