Fancy wifi provisioning

[gorbit99]

Depends on #435

Attempts to implement #71

This PR reworks the wifi provisioning, which originally used SmartConfig, to instead use an ESP-Now based implemenation.

If a tracker is given the "START PROVISION" serial command or the "StartWifiProvisioning" packet (ID 28) while it's connected to a Wi-Fi, it enters provisioning mode. During this it sends out advertisement packets to the trackers around it.

If a tracker doesn't have Wi-Fi credentials set or can't connect using them, it will start listening to these advertisement packets. After a short authorization back and forth, the provisioner tracker sends the target the wifi credentials, using which it can connect to the wifi.

The target tracker sends packets back to the provisioner, reporting its status or any potential failures it encounters.

The following image describes the behaviour of the feature:

Security:
It seems that ESP-Now can't really go through walls. This, combined with the fact that a potential hacker would need to use a device compatible with the protocol and do that in the 1 minute available for provisioning makes the process quite unlikely to be exploited.

TODO:

• Finetune timeout and interval parameters. Increasing the latter might make catching packets a bit more consistent
• Test extensively, both on ESP8266 and ESP32

[Eirenliel]

Kind of a big change for the next release that will go into prod, so i think it;s better to postpone the merge.

[Bluebie]

I feel uneasy about devices sharing WiFi credentials to anything that asks, over the air, without user interaction to explicitly authorise it. It's good that it's only available during active provisioning, but I think it's worth considering going further:

• Should users be asked if they want to enable this functionality so they can make their own choice about how secure they want to keep their WiFi network?
• Maybe the wired provisioning hub device should relay a list of every discovered device to the slime server UI, which could expose the device name and any other identifying info (mac addr? vendor name?), with an "Add" button or similar to explicitly authorise that radio discovered device to receive provisioning?
• Consider setting the ESP-NOW PMK and LMK security keys to something unique to slime, so casual sniffing of wifi packets with software that maybe familiar with ESP-NOW but not specifically designed to target slimes, doesn't automatically get to decrypt wifi password info.
• If firmwares can accommodate the weight, it would be lovely to include something like noise crypto or tweetnacl libraries and use asymmetric crypto to generate a unique public/private keypair and secure these provisioning messages against casual sniffing inside a unique ephemeral channel, so successful attacks would require transmitting a unique provisioning request and not just knowing the default sdk preshared keys (which i think are currently left on esp-now defaults?) or hard coded project keys (if we change the defaults in firmware)

Notably the esphome project is already using noise crypto on a wide variety of commercial IoT products very successfully across almost all of Espressif's chipsets, and also on RP2040 and a few other ultra cheap wifi chipsets, so we can be confident it will perform well on the most commonly used microcontrollers for WiFi slimes. Since WiFi Provisioning doesn't affect the smol slimes, i think we can ignore nordic semi compatibility (though in principal it should work there too, i think)

[ImUrX]

I understand the authorization for sharing wi-fi password but also the communication range is also very short according to the caveats section