Image header improvements and bugfixes

[maxwase]

The original idea was to add ESP32S3 32MB flash support, but then I've discovered some bugs in current implementation such as

• Wrong image size & frequency serialization
• Incomplete header copying (min_chip_rev_full, max_chip_rev_full)

This PR also includes some documentation and interface improvements, as well as support for new flash sizes.
Workaround for #370

Testing

• This was tested on ESP32C3 4Mb and ESP32S3 32Mb
• OTA test
• Regenerated image header diff (entry and max_chip_rev_full):

1,2c1,2
< 0000 0000: E9 04 02 20 E0 10 0D 40  EE 00 00 00 00 00 00 00  ... ...@ ........  
< 0000 0010: 00 FF FF 00 00 00 00 01  20 00 40 3F 6C 2E 00 00  ........  .@?l...  
---
> 0000 0000: E9 04 02 20 88 06 0D 40  EE 00 00 00 00 00 00 00  ... ...@ ........  
> 0000 0010: 00 00 00 00 00 00 00 01  20 00 40 3F C0 25 00 00  ........  .@?.%..  

[SergioGasquez]

Thanks for your contribution! I think it's a more clean way to handle image headers, just left a few small comments. Do you mind resolving the conflicts? Once they are resolved I'll do tests it flashing a few devices

[jessebraham]

I've just taken a cursory look at these changes and they look really great, thanks for fixing all of this. Clearly I missed a number of things during my big refactor last year 😅

I will do some testing and take one more look at the code over the next couple days here. I have merged another PR adding some documentation so there are unfortunately a few merge conflicts, if you wouldn't mind rebasing this please in the meantime that would be appreciated! Sorry about that.

[maxwase]

Thank you for review, rebased & updated some docs, let me know if you want to change doc format somehow

[maxwase]

Btw, I'm not familiar with your version bumping policy, do I need to change it in this PR?

[jessebraham]

I did some testing today and things are looking pretty good here, thanks again for all your work! With the exception of the ESP8266 (which I've commented on above) I think everything seems to be working as expected.

One small detail I did notice, since the ESP32-C2 does not support 40MHz as the flash frequency, and this is the default value, we do get an error when trying to flash without explicitly providing the --flash-freq option:

Chip type:         esp32c2 (revision v1.0)
Crystal frequency: 40MHz
Flash size:        4MB
Features:          WiFi, BLE
MAC address:       10:97:bd:f1:e4:48
Error: espflash::unsupported_flash_frequency

  × The specified flash frequency '_40Mhz' is not supported by the esp32c2

This isn't great UX, but also can probably be handled in a separate PR. If you'd like to tackle it here you're of course welcome to, but it's up to you.

Btw, I'm not familiar with your version bumping policy, do I need to change it in this PR?

Nope, thanks for asking though! There are a few open PRs we'd like to merge and then we will publish a new release candidate.

[maxwase]

This isn't great UX, but also can probably be handled in a separate PR. If you'd like to tackle it here you're of course welcome to, but it's up to you.

Good catch! I see 3 ways of implementing this:

1. Override in main (not so beautiful, but really simple)
2. Make default method, that accepts Chip (kinda duplicate functionality with Default trait, might be confusing)
3. Add flash frequency to Esp32Params struct (IMHO this looks the best, but this is too complex for this PR, it might be that size should also be moved)

I guess it is better to leave it as is in this PR, but fix it later

[jessebraham]

Thanks for making those changes! Also, thanks for the suggestions RE the C2; I'll open an issue for it.