esp_dpp: Fix retry with esp_supp_dpp_start_listen after failure (IDFGH-9508)

[jasta]

This fixes a subtle bug in which ESP_ERR_DPP_TX_FAILURE errors would call esp_supp_dpp_stop_listen which sets the s_dpp_stop_listening flag to true. Subsequent attempts to restart listening with esp_supp_dpp_start_listen then only attempt to listen once more for 500ms before reading the s_dpp_stop_listening flag again and giving up.

The lack of this fix contributes greatly to #10615, but I don't think this fix addresses the root cause. With this fix, it typically works but sometimes requires manually retrying it in the phone UI a couple of times. Without this fix, any number of retries by deinit/init again will seemingly not work as the retries seem to lose too much state or are not done quickly enough to realistically work around the issue, most likely due to a timing race condition somewhere I can't identify.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jasta]

In my opinion it actually makes more sense to silently keep retrying for a longer period than 500ms (the spec seems to suggest 5s is reasonable). Further, upon looking into the DPP protocol it seems that there is a new version 2 available and stable that addresses some of the channel misalignment issues we seem to be experiencing. wpa_supplicant on Android is running this version and is even advertising that it wants to use version 2, but wpa_supplicant even in v5.0.1 is using a very old version with only DPP1 support. I recommend upgrading wpa_supplicant as a way of fixing the issue properly, though I can't say for sure this will fix it ATM.

[jasta]

For context, the dpp-enrollee sample tells us that we should call esp_supp_dpp_start_listen upon error, but it doesn't work for the reasons outlined in this issue.