mdns library deinitialization destroys internal structures including action queue. if an event (e.g. network update) received
after some essential stucture is destoyed, an unexpected behavour might be introduced (e.g. crash of adding the event notification
to the action queue which was already destroyed
Closes WIFI-1485
Added default sdkconfig for qemu build for the mqtt publish example,
Added environment configuration for running the same test on target
or in qemu
Updated missing example tests per latest ttfw refactoring
esp_netif_init() returns standard esp_err_t error code (unlike tcpip_adapter init), so shall be checked for the return value
Also to make the initialization code more consistent.
Also added guide for creating a custom network capable I/O driver
And added notes about default wifi interfaces and implications of using
default short-hand creation functions.
mdns module store local copy of esp_netif for common interfaces,
but it was correctly initialized only when interface started.
If the event were missed (e.g. mdns_init after interface start)
the local copy wouldn't be initialized. Fixed by restoring the local
copy.
Closes WIFI-1538
Latest versions of apt-get don't install as much packages by default
as older ones. This fix adds some missing packages discovered for an OS
derived from the latest stable Debian. These packages exist for older
Debian derivatives as well (tested with Ubuntu 16.04 LTS).
Closes https://github.com/espressif/esp-idf/issues/4480
ledc_types.h includes two similar enums, ledc_clk_src_t & ledc_clk_cfg_t. Latter was added in
ESP-IDF v4.0.
The two enums do different things but there are two similar names: LEDC_REF_TICK / LEDC_USE_REF_TICK
and LEDC_APB_CLK / LEDC_USE_APB_CLK.
Because C will accept any enum or integer value for an enum argument, there's no easy way to check
the correct enum is passed without using static analysis.
To avoid accidental errors, make the numeric values for the two similarly named enums the same.,
Noticed when looking into https://github.com/espressif/esp-idf/issues/4476
Previous version used exception handling for program control flow,
which makes for long and confusing backtrace messages if an error
occurs while parsing the CSV (as it also prints the phony error that
occurred while trying to parse as a binary, then prints
"During handling of the above exception, another exception occurred:",
then prints the real error).
Use the same heuristic that is applied in gen_esp32_part, instead.
Also, avoid printing the entire backtrace if the error is a gen_esp32_part
InputError, same as gen_esp32part does.
Found while looking into https://github.com/espressif/esp-idf/issues/4474
Before handling status message, client models need check if the
corresponding timer has expired. And if timeout happens, the
status message will be treated as a publish message.
