policy: don't track roam_scan_done

Don't determine a finished client scan based on whether the current node
has seen a beacon or not.

This works surprisingly bad on 5 GHz nodes, as clients may refuse to
perform active scanning on this frequency band. In case the clients does
refuse to scan the 5 GHz band but scans the 2.4 GHz band actively, we
might have a good indication about a better node on this band at least.

However, as the roam state-machine requires to have seen a probe request
from the client to direct him to a better node, thi process will not
continue, which either ends the node in being kicked due to exceeding
the number of max tries or the scan cooldown to kick in.

The solution to this is fairly simple: Don't track the roam_scan_done
state but instead just determine a better candidate after the scan
interval finished.

To ensure the indicated signal levels are as recent as 2 *
scan-interval, add a max_age parameter to find_better_candidate.

Signed-off-by: David Bauer <mail@david-bauer.net>

usteer.h

@@ -229,7 +229,7 @@ struct sta_info {
 	uint8_t roam_tries;
 	uint64_t roam_event;
 	uint64_t roam_kick;
-	uint64_t roam_scan_done;
+	uint64_t roam_scan_start;
 	uint64_t roam_scan_timeout_start;
 
 	int kick_count;