Add FOTA Service mock example

[noonfom]

This PR adds a mock (i.e. no bootloader) example for the FOTA service.

Co-authored by @AGlass0fMilk

[noonfom]

For now, let's use my mbed-os fork as ARMmbed/mbed-os#14574 is stuck in review.

[pan-]

Excellent submission @noonfom. Once it passes CI we can merge and iterate.

[pan-]

I think this should be to 19 so it will work on all targets. Ideally we would get the MTU of the link and derive fragment size from it. There's a PR open in Bleak for that: hbldh/bleak#525 .

[noonfom]

It can't be 19 as that is not a multiple of the program block size (= 4 for nRF & DISCO). In general, this is a QSPIF configuration option that we can override in mbed_app.json:

{
    "target_overrides": {
        "*": {
            "QSPI_MIN_READ_SIZE": "19",
            "QSPI_MIN_PROG_SIZE": "19"
        }
    }
}

Since 19 is prime. That will only work for nRF and DISCO which use QSPIF. Targets with a different default block device instance will require separate overrides.

[pan-]

That's interesting, we probably need some sort of buffering in the client side to accommodate between the block size and packet length.

[noonfom]

I'll leave this open as it's a good observation and the bleak PR is worth keeping an eye. However, a fragment size of 128 data bytes + 1 fragment ID byte (=129 bytes) should work on nRF and DISCO due to the cordio.desired-att-mtu override in our mbed-app.json. Making this 19 would also affect the transfer speed. We can iterate on this PR once it lands in the FOTA service example branch. For now, perhaps we can simply add a note about hardware support in the README?

[pan-]

How do you handle the case where the last fragment is not received ? It seems to go out of this loop but a new status can be posted by the server.