samples: common: wifi: handle DISCONNECT_RESULT wifi_mgmt event and change retry interval

So far only CONNECT_RESULT wifi_mgmt event was handled. This should be enough with properly functioning WiFi drivers, which should use that event for either succeeded or failed connect attempt (status code is always passed with CONNECT_RESULT, which defines whether it was a success or failure). However current implementation of ESP32 WiFi driver seems to not respect wifi_mgmt APIs and sends DISCONNECT_RESULT wifi_mgmt result on failed connect attempt.

Handle DISCONNECT_RESULT events and treat that as if CONNECT_RESULT was received with -EFAULT status code was received. This workarounds current ESP32 WiFi driver implementation. This driver needs to be fixed anyway, but more drivers might appear in the future with such broken behavior.

So far there was fixed 5s interval between subsequent connect attempts. This was fine for perfectly working WiFi drivers, which should only fail to connect in case of random and very rare radio issues.

Seems that current ESP32 WiFi driver fails to connect in the first attempt in more than 50% of cases (at least with single tested AP). For some reason second attempt is always successful and simply adding 5s delay before first attempt doesn't affect success rate of the first attempt. This means there will often be two connect attempts in order to connect to WiFi AP. Leaving harcoded 5s interval between attempts makes all samples in need of additional 5s to connect to cloud.

Switch from hardcoded 5s interval between connect attempts to exponentially increased interval starting at 0.5s. Such short interval will minimize time for ESP32 to connect to cloud, while still allowing sample code to wait for any temporarily unavailable AP by increasing interval up to 30s in the subsequent connect attempts.

golioth / golioth-zephyr-sdk

samples: common: wifi: handle DISCONNECT_RESULT wifi_mgmt event and change retry interval #302