Espflash Refactoring

• The current structure has resulted from organic growth over the years, but cracks are starting to show and it's becoming increasingly difficult to add new functionality in some cases
• One major issue is the Flasher struct, which has become a bit of a dumping grounds for various functions
  • This probably could be split up; how we approach this is still unclear to me
• There are various cyclic dependencies between modules which should be resolved
  • This makes maintenance and extension more difficult than it needs to be, and is generally just considered bad practice from an architecture viewpoint
  • Some types probably need to be shuffled around a bit, as not everything lives where it probably should
• We are leaking some types from dependencies which are not 1.0 as well, which needs to be resolved
• We need to come up with one or more traits which are generic enough to add new image formats in a non-breaking way
  • I think for the image format itself this is probably not too bad, APIs which return RAM/ROM segments or something is probably enough to get us there
    • SM: Some formats, including esp-idf's and I guess MCU boot requires that all ROM code is sequentially. If we expose segments in this way, can we still guarantee we don't have any gaps? I suppose this might be considered a bug in the image format implementation if this happens?
  • This gets tricky with metadata however, e.g. our current app/partition size, etc. metadata may not be application to all formats
    • SM: I think there are quite a few solve this: assoc type in a trait, maybe tying the data to the image format enum and probably a few more. I'm not familiar enough with espflash to know what approach is best though
• I'd still like to try and make as many types/functions/etc. private as possible as well
  • SM: +1, smallest possible API surface is definitely a goal here
• SM: We should also keep in mind espflash library usage, like in probe-rs, when we're thinking about this refactor
• SM: To me it seems FirmwareImage trait, is trying to abstract at the wrong level. All input firmware will be elf files, any binary or hex files etc. will be written directly to flash without needing to worry about the format the binary is. I think what we should be abstracting over is the image format, i.e how to take code segments and turn them into the specified format. We might not need a trait here, an enum might be enough.
  • This is turning into a bit of a ramble (sorry), but perhaps the way to untangle this is to think about the flow of data, from inputs (cli, elf) to outputs (image format, and eventually flashing)
  • get_flash_image is very esp-idf specific, detangling this will probably untangle a bunch of other things (and also solves https://github.com/esp-rs/espflash/issues/745)