For swap using scratch, the boot_read_image_header routine, responsible
for reading the image headers, was always looking for the primary and
secondary image's headers at the beginning of respectively the primary
and secondary slots, regardless of the current boot status.

This means if during a swap-scratch upgrade a reset happens after the
sector containing the image header in the primary or secondary slot has
been erased, invalid image headers were read since at that time the
location of the headers has changed.

Currently, this doesn't seem to cause any issue because the swap-scratch
algorithm is implemented in such a way the content of the headers is no
more necessary when the headers are erased. However, to be able to
decrypt the secondary image when copied to the primary slot instead of
when copied to the scratch area, properly reading the secondary image's
header is required even after it has been erased from the secondary
slot.

To that end, the boot_read_image_header is modified to determine from
the boot status the current location of the image headers and to always
read the actual header, no matter the current state of the upgrade
process.

Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>

Currently, when swap using scratch is used with encrypted images,
MCUboot is decrypting the images during the copy from the secondary slot
to the scratch area. This means the scratch area contains plaintext
image data and therefore that the scratch area must be placed in the
MCU's internal flash memory. This commit makes the necessary changes to
perform the decryption when copying from the scratch area to the primary
slot instead, making possible to place the scratch area in an external
flash memory since the scratch area is now encrypted.

Note that BOOT_SWAP_SAVE_ENCTLV must be enabled if the scratch area is
placed in external flash memory.

Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>

When using swap using scratch, the decryption now happens when copying
from the scratch area to the primary slot, which means the image is
stored encrypted in the scratch area. This commit updates the
documentation accordingly.

Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>

When 'direct-xip' or 'ram-load' features were enabled,
CONFIG_BOOT_SWAP_USING_SCRATCH and MCUBOOT_SWAP_USING_SCRATCH were
defined even though swap using scratch wasn't used. This commit fixes
the issue.

Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>

Add release note snippet regarding the change made to the swap with
scratch algorithm to avoid having plaintext firmware data stored in the
scratch area.

Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>