xtensa/esp32: use common Espressif wireless source

[fdcavalcanti]

This PR is the second part of the WiFi common layer port for Espressif Xtensa devices.
ESP32S3 has been recently merged here #15816.

Summary

This PR modifies ESP32 to use WiFi source code from the common layer, which is already used by ESP32S2 and ESP32S3. KConfig prefixes such as ESP32_* are replaced with ESPRESSIF_* (CONFIG_ESP32_WIFI -> CONFIG_ESPRESSIF_WIFI). This is applied through arch/ and also board/.

BLE symbols are altered as well, since they share some common wireless implementations. However, source code for BLE has not been merged into the common layer.

Impact

• Impact on User: KConfig changes will cause issues to users who have custom defconfigs, as they should now update the wireless symbols.
• Impact on Build: Not in practice, but some build instructions are removed from arch/xtensa/src/esp32 and merged into arch/xtensa/src/common/espressif.
• Impact on Hardware: Affects only ESP32S3 boards.
• Impact on Documentation: No.
• Impact on Security, Compatibility: Only compatibility issue is the KConfig symbols mentioned above.

Testing

Internal CI testing +
sta_softap, wifi, ble, blewifi defconfigs (among others) have been tested and are performing as expected.

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although some minor improvements could be made. Here's a breakdown:

Strengths:

• Clear Summary: The summary explains the "why," "what," and "how" of the changes. The reference to the previous PR (xtensa/esp32s3: use common Espressif wireless source #15816) is helpful for context.
• Impact Assessment: The impact section addresses all the required points. The description of the user impact (KConfig changes) is particularly important.
• Testing Information: The testing section provides information on the host and targets used for testing. Mentioning specific defconfigs tested is good.

Areas for Improvement:

• Missing Issue References: While the previous PR is mentioned, it's beneficial to link a related NuttX or NuttX Apps issue if one exists. Even if this PR is purely a refactoring following from a previous issue, referencing that issue is helpful for traceability.
• Testing Logs: The PR claims testing logs are included, but the provided template sections are empty. Actual log snippets demonstrating functionality before and after the change should be included. This provides concrete evidence of successful testing. If logs are too extensive, consider providing a link to an external log file or CI run.
• Hardware Impact Clarification: The impact on hardware states "Affects only ESP32S3 boards." However, the summary mentions modifying ESP32. This discrepancy should be clarified. Does it affect both ESP32 and ESP32S3 or just ESP32S3? If ESP32S3 was already transitioned in the previous PR, that needs to be stated more explicitly, as the current wording implies this PR is the first change for the ESP32S3.
• Build Impact Nuance: While the practical build impact is minimal, the movement of build instructions is a change, even if minor. Acknowledging this explicitly and mentioning the specific files affected adds clarity.

Recommendation:

The PR is close to meeting the requirements. Adding the missing issue references, including actual testing logs (or links to them), and clarifying the hardware and build impact will strengthen the PR and make it easier for reviewers to assess.

[acassis]

Please give some hints about that are these optimization. Why are they important? And why did they are enable by default?

[fdcavalcanti]

It's actually disabled by default.
Those are used for dynamic allocation of the buffers used on the WiFi. Seems to be a legacy thing from ESP32.
In fact, this will be probably removed soon as I'm testing an upgrade on esp_wlan.c to use IOBs.

[tmedicci]

This is the same PR of #15816 but for ESP32.

I've already reviewed it at #15749