dfu: new design features

[mniestroj]

Current implementation of DFU by observing single CoAP /update resource is very simple, but also very restricted in design. This Issue is a collection of nice to have features, which we want to take into account when designing a more powerful and flexible DFU mechanism. This list includes ideas for both cloud part as well SDK part.

• be able to store multiple firmware versions "in golioth" instead of always providing local file, which might be useful to have "phased rollout" with group of devices
• delta firmware upgrade - support DFU by sending diff of two firmware images, in order to reduce network bandwidth (tested bsdiff some time ago and simple changes in 200k firmware could result in 3k of diff binary, while significant code changes were still around ~50k, i.e. 25% original size); might be useful for some applications
• allow more control over DFU process, so that:
  • downloaded firmware on device is not automatically selected for upgrade on all devices; instead in some situations it might be desirable to transfer firmware to group of devices and only then mark that firmware as bootable on all devices at once,
  • newly booted firmware is confirmed by cloud after it successfully connects back to golioth or adding some status on progress of DFU,
• supporting multiple image DFU (e.g. to upgrade nrf52+esp combo),
• support XIP images (e.g. mcuboot's BOOT_DIRECT_XIP):
  • In order to prevent application swap, we can prepare 2 variants of the firmware. First one will support running from the first application slot, where second will support running from the second application slot. Those two variants would need to be uploaded to cloud (golioth). During firmware download process, we should somehow figure out which firmware variant should we download and flash (depending on which application slot are we running from now).
  • What will we gain by supporting this option:
    • faster "reboot from older to newer firmware" - this would address quite long time (up to ~1min for ~500kB firmware) that is needed for swapping two application images,
    • faster revert to previous firmware (in case of any errors),
    • smaller bootloader size, just like the BOOT_DIRECT_XIP option description says; this means more space for applications that uses golioth SDK,
    • smaller flash wear (it shouldn't be a problem in most cases, but it still improves it a bit).
  • Downsides:
    • requires building of two firmware variants,
    • golioth server and/or golioth SDK needs to be aware of those two firmware variants and choose the correct one (bit more complex).