[Gen 3] Fix warm boot; [Tracker] Cache ESP32 firmware version

[avtolstoy]

Problem

1. We've introduced a regression in Gen3: Network management improvement #2217 and broke warm boot
2. During handshake with the cloud we need to send ESP32 NCP firmware version as it is one of the module, so it's present in the system describe. On Tracker during the cloud connection establishment it's not guaranteed that ESP32 is on, so we have to turn it on in order to query for its version, which prolongs the handshake process. What complicates things even more is that since Gen3: Network management improvement #2217 we'll also watch the current NCP state closely and power off immediately, so several sequential calls to query ESP32 NCP firmware version may have to power on the ESP32 and initialize it multiple times

Solution

1. Keep the NCP state as-is unless some command (on, off, up, down) is submitted
2. Cache ESP32 NCP firmware version in non-volatile memory and read it from there

Steps to Test

1. Use an app with SEMI_AUTOMATIC modem and suspend the connection process for some time. Wait until the device connects to the cloud, reset with a button, watch the logs - it should reconnect without powering off the NCP
2. Watch the logs, make sure that ESP32 firmware version is taken out of cache: Cached ESP32 NCP firmware version
3. Update ESP32 NCP OTA, watch the logs, make sure that ESP32 firmware version changes and gets taken out of cache.

For step 3, the following 0.0.8 ESP32 NCP firmware can be used: tracker-esp32-ncp@0.0.8.zip

Example App

N/A

References

• [CH71350]

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[XuGuohui]

Nit: const?

[avtolstoy]

Can't do const as TlvFile::get() modifies the internal state and cannot be const either, unless we make some member variables mutable.

[XuGuohui]

How about do this in the Esp32NcpNetif::loop before entering the while loop like we do to the Argon to fetch the MAC address? Just to be consistence to initialize things in one place.

[avtolstoy]

This method will get called multiple times throughout the device runtime, so this is the appropriate place to look into cache first and then fallback to calling into ESP32 itself to get the version (and update the cache).

If we are thinking of checking/updating the cache on early boot as we do with a MAC address on an Argon, this is disabled on Tracker already, so that we don't unnecessarily boot ESP32 every time we boot Device OS. Eventually using the caching that was implemented here we'll do the same for MAC address. So, I'd prefer to keep things on as-needed basis.