Support FS update in two steps

[Androbin]

Problem: I am updating my sketch and FS over HTTPS and keep the certificates in FS like in the httpUpdateSecure.ino example. If updating the FS fails (e.g. power failure during download) and the certificates get damaged, my customers might not be able to update and recover anymore.

Solution: Support the same two step process that is used to update the sketch.

A step towards #905. Hopefully the option to move from RTC to flash will be merged soon also.

[d-a-v]

where or when is UPDATE_IN_TWO_STEPS supposed to be defined ?
Is this PR dependent of #6533 ?

[Androbin]

@d-a-v It's an independent effort. I'm using #ifdef, so not defining it is the point.
As long as this flag is not defined (by the user), it will default to the current behavior.

[d-a-v]

Can you elaborate on how this is supposed to be used when UPDATE_IN_TWO_STEPS is defined ?

[earlephilhower]

The FS is presently updated right in Updater.cpp during the upload, and can end up in an inconsistent state should there be a dropout or other problem during update.

It's not like the app where the new copy is only uploaded if the entire upload and MD5 match. What this looks to do is treat the FS the same way as the program, and upload to spare area and only ask the bootloader to overwrite it iff the upload is a success.

[earlephilhower]

This makes sense to me. Need to leave it as optional since in most cases you don't have enough unused space to do this 2-step process.

[d-a-v]

I understand UPDATE_IN_TWO_STEPS is only used for FS, so can this macro be renamed to make this code more easily readable ?

[earlephilhower]

@Androbin can you see to @d-a-v's request? Maybe ATOMIC_FS_UPDATEor UPDATE_FS_IN_TWO_STEPS?

Also, now that I think about it, a short note somewhere in the docs/ota_updates about this define (since it seems unintuitive to some people) would be appropriate.

[Androbin]

I renamed the flag and left a note in the docs as suggested.