Esp32 WiFi AP+STA fix and WiFi scan support

[atanisoft]

1. When operating as a STATION and SOFTAP mDNS should only be initialized once, the second start will cause a restart of the node.
2. Start of async SSID scan support. For SSID scan it is required to start the station interface, so for SoftAP only mode the code will set the interface mode AP+STA but only start the AP.

@balazsracz @bakerstu feedback on SSID scan API, it is pretty raw currently and we talked about the possibility of a common API layer and I'd like to work towards that but this is a first pass using the IDF native object types.

[atanisoft]

example VERBOSE output from scan:

SSID: TheHomeNet, RSSI: -67, channel: 6
SSID: Fool of a Took, RSSI: -70, channel: 11
...

An example of it's usage can be seen here.

[balazsracz]

I think this API is fine; I have two general comments:

1. we should not have APIs that leak #includes of the underlying host system.
2. we probably want to refactor the CC32xxWiFi and the ESP32WiFiManager to share the same APIs wherever possible.

2 is only possible if we keep to 1; the CC32xxWiFi was implemented according to the requirement of 1.
The wifi scan APIs are however mildly incompatible, because the 3220 does not have a notification when the scan is complete (which is a huge deficiency of the 3220 but we can't do anything to fix that).

I believe we should merge this now, and at some point in the future work on abstracting the wifi APIs, thereafter we can rework the ESP32WiFiManager as well.

[balazsracz]

const wifiap_record_t& as return

[atanisoft]

done

[balazsracz]

sorry this was a wrong advice. it does need to be returned by value.

[atanisoft]

• we probably want to refactor the CC32xxWiFi and the ESP32WiFiManager to share the same APIs wherever possible.

Yes, I have the old proposed API which I'll put on a branch and we can adjust and migrate in parallel to a common "generic" API.

2 is only possible if we keep to 1; the CC32xxWiFi was implemented according to the requirement of 1.
The wifi scan APIs are however mildly incompatible, because the 3220 does not have a notification when the scan is complete (which is a huge deficiency of the 3220 but we can't do anything to fix that).

Yes, the common API will remove the system types from the API and allow both sync/async APIs where possible. For systems which do not support an async API it can either raise an error or perform the action as sync, in the case of the scan the proposed API is:

    /// Starts an access point scan.
    ///
    /// Note: This API will only execute *ONE* network scan per call.
    ///
    /// @param blocking will cause this method to block until the network scan
    /// completes. Default is non-blocking.
    /// @param timeout is the number of milliseconds to allow for the network
    /// scan to complete. This is only valid when @ref blocking is true.
    /// @param max_results is the maximum number of results to scan for. If the
    /// WiFi interface supports a lower number than requested and in such case
    /// the WiFi interface supported limit will be used instead.
    ///
    /// @return the number of networks found via scan, this value will be zero
    /// when @ref blocking is false.
    virtual int network_scan_single(bool blocking = false, uint32_t timeout = 0,
        uint8_t max_results = 20) = 0;

    /// Starts a continuous access point scan.
    ///
    /// Note: When there is already a network scan running, this will API will
    /// be treated as a NOOP.
    ///
    /// @return @ref WiFiErrorCode as the result of starting the network scan.
    virtual WiFiErrorCode network_scan_start() = 0;

    /// Stops a continuous access point scan.
    ///
    /// Note: When there is not a network scan running, this will API be
    /// treated as a NOOP.
    ///
    /// @return @ref WiFiErrorCode as the result of stopping the network scan.
    virtual WiFiErrorCode network_scan_stop() = 0;

    /// Retrieves a list of available access points.
    ///
    /// @param list will contain a list of available network entries. Note this
    /// will be cleared prior to appending the retrieved entries.
    ///
    /// @return @ref WiFiErrorCode as the result of retrieving the network
    /// list. When the network scan has not been completed this API should
    /// return @ref WiFiErrorCode::NETWORK_LIST_UNAVAILABLE.
    virtual WiFiErrorCode get_network_list(
        std::vector<NetworkListEntry> *list) = 0;

In the case of the ESP32 the network_scan_start()/network_scan_stop() methods would likely return a generic error code as un-supported since there is no continuous scan support on the ESP32 that I have found (unless it is done via a background task that calls async scan repeatedly)

I believe we should merge this now, and at some point in the future work on abstracting the wifi APIs, thereafter we can rework the ESP32WiFiManager as well.

Yes, I don't think we need to hold this (outside of the above feedback items). The rework can be done in parallel to a new common API (PR coming shortly for discussion on the interface only)

[atanisoft]

This has a bug in the mDNS code which I've fixed in my CS copy of this. I'll be submitting an update to this branch after cleaning it up further.

[atanisoft]

@balazsracz this is now up-to-date with latest tested changes from the CS side, can you do a review on this for anything that needs adjustment prior to merge?

[balazsracz]

fyi this code is not correct, because the mutex is released but a reference to the storage area is returned to the caller.

[atanisoft]

Ok, let me send in an update PR with this changed to return by value.