bootutil: Store image encrypted in scratch area

[taltenbach]

Description

As discussed on https://github.com/mcu-tools/mcuboot/issues/1942, when swap using scratch is used, the image is currently decrypted while copying from the secondary slot to the scratch area. This means even when BOOT_SWAP_SAVE_ENCTLV is enabled, the scratch area has to reside in the MCU's internal flash memory.

However, being able to place the scratch area in an external flash memory could be valuable since:

• It would enable to have more space available in internal flash memory, which could be used e.g. the increase the size of the primary slot(s).
• There is typically more space available in external flash memory, which would make possible to have a larger scratch area, reducing flash wear.
• The external flash memory might have higher endurance than the internal flash memory, increasing the number of possible updates.

This PR proposes changes to perform the decryption while copying from the scratch area to the secondary slot instead, meaning the scratch area does not contain plaintext image data anymore.

The reason why this wasn't performed that way in the first place is probably that it introduces an issue when the device is reset after having erased the first sector of the secondary slot but before having copied it from the scratch area to the primary slot. Indeed, for being able to properly decrypt an image, MCUboot needs the header of that image (cf. boot_copy_region). This header is located at the beginning of the secondary slot until the first sector of the secondary slot is processed. At this time:

1. The secondary image's header is copied to scratch area.
2. The secondary image's header header is erased in the secondary slot and replaced by the header of the primary image.
3. The primary image's header is erased in the primary slot and replaced by the header of the secondary image.

If a reset occurs after step 1, the secondary image's header might not be located anymore in the secondary slot but is still needed when using encrypted scratch since the first segment of the image has to be decrypted during step 3. However, when using swap using scratch, MCUboot is currently always looking for the primary and secondary image's headers in respectively the primary and secondary slots, regardless of the current boot status (cf. boot_read_image_header). Therefore, this MR also modifies the boot_read_image_header routine to properly load the image headers, according to the current progress of the upgrade.

Tests

• Simulator OK with enc-x25519, enc-x25519 multiimage, enc-x25519 overwrite-only, enc-x25519 ram-load, enc-x25519 swap-move and direct-xip.
• Update and revert on an STM32F413-based device, with two encrypted images and scratch area in external flash memory.