Clarify implementation flexibility in when the staging area is physically erased

[athoelke]

In the Firmware Update API 1.0.0, the intent of the psa_fwu_clean() function was to allow Update clients that were sensitive to the timing of long-running or disruptive operations (such as erasing blocks of flash memory) to control when an implementation would erase the staging area in preparation for a new update.

In the description of psa_fwu_clean(), it is clear that carrying out a physical erase operation on the staging area memory is not required to be done at this stage, but is recommended for implementations that are used where such client concerns are relevant:

If the implementation needs to perform long-running operations to erase firmware store memories, it is recommended that this is done as part of psa_fwu_clean(), rather than during other operations. This enables the update client to schedule this long-running operation at a time when this is less disruptive to the application.

This is the intended understanding of the clean operation.

However, the name of the API, and the wording in general in 4. Programming model regarding the clean operation, gives a strong impression that flash erasing must be done during a call to psa_fwu_clean. For example, see 4.2.3 State transitions.

It would be helpful to reflect a consistent message regarding the flexibility and recommendation for erasing during clean throughout the specification. This removes ambiguity for implementations where erasing the memory can be done efficiently and non-disruptively when new firmware is being written (during psa_fwu_write()). Such implementations are then obviously permitted to just record the transition to the READY state in response to a call to psa_fwu_clean().