If the link to the current AP fails, that's either because it is out of range
or somebody turned it off, or the driver is being dumb.  Instead of leaving
the failed AP in the scan list, whereupon we'll just try reconnecting to it
again (even though it might not be visible), remove it from the list and
only try reconnecting if a new scan finds it.  To ensure that happens, start
a scan when entering the DISCONNECTED state, which the device enters
right after FAILED.

Now there's a race between the periodic update and the link timeout
handler, as the periodic update could have run right before the link
timeout, and if the card was momentarily unassociated when the periodic
update fired, priv->current_ap will be cleared, and thus we can't remove
it from the internal scan list.

To fix that, only run the periodic update when we know the supplicant is
talking to an AP.  When it's not talking to an AP the information that
the perioidic update gathers is meaningless anyway.  Plus, it's not very
helpful to clear the current AP just because the driver/supplicant are
in a transient state; if they recover the connection we've bounced
stuff unecessarily, and if they don't recover we'll be tearing the
connection down anyway.