wifi: more disconnect reasons for retries & include error code in exception

[anecdata]

Changes

Based on goals and discussion in #3837:

• expand retries to all reasons for disconnection except for: the two current fatal reasons that raise an exception (NO_AP_FOUND==201 and AUTH_FAIL==202); and the one reason that arises when user code manually triggers a wi-fi disconnect or stop (ASSOC_LEAVE==8)

• return the error code for exceptions that don't currently have specific error strings (used to be just "Unknown failure")

For example,

W (242170) wifi: reason 205 0xcd

will raise to user code:

ConnectionError: Unknown failure 205

Discussion

I've tested this in various scenarios with Peplink and Apple APs, and there is slight variation in disconnect reason codes that arise from various actions. I'd expect other equipment to potentially have other variations. So I'd like more eyes on this code, and hopefully some testing by others in different environments too. I'm open to further tweaking the disconnection reasons we raise exceptions for, and further tweaking the reason logic in the event handler.

The most questionable thing here I think is the slight muddling of the shared-bindings / common-hal interface with the wifi_radio_error_t enum and returning the reason number from common-hal. Every known disconnect reason is now in the enum, and WIFI_RADIO_ERROR_UNKNOWN is no longer needed. The alternative (especially if the error number is considered inelegant), assuming we want specific errors known to users (very useful for troubleshooting), is to itemize each of the 30+ disconnect reasons as a unique error string. Or perhaps raise the Espressif-specific exceptions in common-hal, and return the IEEE-based codes to raise in shared-bindings. Or perhaps there's another solution I'm not aware of.

The saving grace is that most of the reasons in the enum are IEEE 802.11 numbers, so should carry over to any future alternate wi-fi-capable ports.

There is a small risk with this code that the IDF returns an unexpected reason code not in the enum (not in their docs). Not sure how to handle this.

[tannewt]

This looks good to me! We can wait a little to merge though since I think we'll be doing a 6.1.0 RC from main shortly. @dhalbert please merge after 6.1.x is branched again. Thanks!

[tannewt]

Oh ya, you'll need to update translations to fix the build.

[tannewt]

Thank you!