MI32 legacy: add mi32name, small fixes

[Staars]

Description:

• Add command mi32name to better handle unknown/new sensors.
  Usage:
  mi32name<slot> <new name>, where slot is the position of the observed sensor in the the internal array (reflected in the order of the sensors after status 8) starting with 0.
  mi32name<slot> will delete the overridden sensor name and use the built-in one.
  When an unknown sensor gets a name, the command mi32cfg will write this to the driver config. It could be changed in the mi32cfg-file too, as this is a JSON.

• An unknown sensor will "learn" its features over time with every received data packet. When all features have been learned, the command mi32cfgwill save this feature descriptor in the mi32cfg-file. It is mandatory to give these sensors a name before.

• Adds MAC to every MQTT message, as with overridden names, the automatically suffixed OUI of the MAC for built-in names will not be there

• Use fetch instead of XMLHttpRequest in the embedded web dashboard JS code

• Reduce the traffic of the embedded dashboard by relaxing the update interval in order to slightly improve the currently observed memory leak of the webserver under Arduino 3.0. This bug will reduce the free heap after each fetch/XMLHttpRequest until there is not enough of it. The the system will likely slow down after awhile and later recover "automagically" as if there is some kind of garbage collection in the background. Did not find the exact reason yet.

• Better handle the slightly changed API of esp-nimble-cpp to catch more sensor messages

• minor refactoring

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works with Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works with Tasmota core ESP32 V.2.0.13
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[barbudor]

Hi @Staars
Could you please give some example of where/when this feature can be used ?
Does it solve #19415 ?

[Staars]

It is somehow related, but the problem in that discussion is another thing.
There is no extensive information provided, it could be wrong usage.
In theory unknown sensors are already supported for awhile, as long as they publish known attributes.
In order to get this to work for an encrypting sensor, this sensor must be known to the system. This will happen after the first received packet. This can be made persistent with mi32cfg and is then known after every reboot.
Then a decryption key can be assigned to the MAC with mi32key <keyMAC-hexstring>. This could be made persistent with mi32cfg too.
In that state the received sensor message should already be published with a name that is a combination of the PID (Xiaomis ID number for this sensor) and the OUI of the MAC.
As this is not super nice to read and I would like to avoid to add more hard coded sensors to the driver, I added the mi32name command to override this name (but it works for the hardcoded „old“ names too). But it is not mandatory to get it to work.