Wait for Wi-Fi management to start up (#8834)

[tewarid]

Problem

What is being fixed?

• Wi-Fi management takes a while to startup asynchrounously on Linux and this causes the app to assume Wi-Fi is not provisioned, reset fabric setting, and continue in pairing mode. What a user perceives is that the device has been unpaired and needs to be paired with again.

Change overview

Poll for Wi-Fi Management to start for five attempts every 100 ms.

Testing

How was this tested?

• Manually tested with all-clusters-app on a custom Linux system build.

[CLAassistant]

All committers have signed the CLA.

[bzbarsky-apple]

@tewarid @andy31415 I'm a little confused by the changes here. We're sleeping and waiting for some state to change... does it get changed by some other thread? If so, where is the synchronization with the other thread? Or are we just touching members from multiple threads without any synchronization?

[tewarid]

@bzbarsky-apple Async DBUS wpa_supplicant proxy initialization in ConnectivityMgrImpl is the source for parallelism - see sequenced calls to wpa_fi_w1_wpa_supplicant1_proxy_new_for_bus, wpa_fi_w1_wpa_supplicant1_call_get_interface, and wpa_fi_w1_wpa_supplicant1_interface_proxy_new_for_bus in src/platform/Linux/ConnectivityManagerImpl.cpp. During program initialization, the only thread changing state is the one on which DBUS callback happens. I don't see why lack of synchronization should lead to non determinism. Async init is perhaps overkill, in hindsight.

[tewarid]

@bzbarsky-apple Although synchronization may not be necessary, state in GDBusWpaSupplicant (src/platform/Linux/ConnectivityManagerImpl.h) should be declared volatile.

[bzbarsky-apple]

the only thread changing state is the one on which DBUS callback happens

@tewarid Yes, but if it's doing unsynchronized writes and this thread is doing unsynchronized reads, then depending on the exact size of mWpaSupplicant.state and the values of various states the value might test to be equal to GDBusWpaSupplicant::WPA_INTERFACE_CONNECTED even if the actual value being written to the member is not.

What we should probably do is just have that state member be an std::atomic to prevent those sorts of problems.