OTA/YModem update result

[avtolstoy]

Implements #1032

When updating the device via YModem:

• After receiving EOT from Host, device doesn't immediately respond with ACK. Instead binary validation is performed.
• If successful, device notifies the Host with ACK and prints received file name and size.
• If validation fails, the device notifies the Host with two CA (CA, CA) as to indicate the error and prints hexademical error code, which is a bitmask of failed checks (https://github.com/spark/firmware/blob/c916faafaea75f802a521d32ca4353aba812dfe2/hal/inc/ota_flash_hal.h#L52)

When updating OTA:

• After successfully receiving the binary, the device performs validation and before rebooting publishes an event spark/device/ota_result, which contains the following JSON object:

{"r": "ok", "u": {JSON ota module info, same format as particle serial inspect}}

• In case of an error, the same object is published. JSON ota module info might not be present

{"r": "error", "u": {JSON ota module info, same format as particle serial inspect, might not be present}}

• A full system module info object + ota module info don't fit into 255 byte publish message limit, so only ota module info is included.

---

Doneness:

• Contributor has signed CLA
• Problem and Solution clearly stated
• Code peer reviewed
• API tests compiled
• Run unit/integration/application tests on device
• Add documentation
• Add to CHANGELOG.md after merging (add links to docs and issues)

Enhancements

• When flashing (OTA/YModem) an invalid firmware binary (that the device ignores) it will post an event describing why the binary was not applied. [Implements #1032]

[m-mcgowan]

We should try to write tests for this:

• unit tests in the user/test/unit package to validate the ymodem code (we can stub most of the system functionality). focus here is on testing tiny pieces of the code.
• integration tests that save the file transmitted via ymodem to the filesystem or RAM so we can verify the file saved matches the one sent
• acceptance tests that use the CLI to flash a file to the device (both a valid and invalid one) and verifies the result.

[technobly]

Add logs for this event ( as in PR #1169 ), dumping the buffer would be a quick way to tell in logs what the result of the OTA/YModem was.

[technobly]

I'm assuming we need this to ensure the publish is sent before we soft reset to apply the OTA update. Can we make this more synchronous, as implemented in PR #1144 ? We can do this as a separate PR after these get merged. I'll take notes on all of these review comments to make sure we don't forget :)

[technobly]

This is fine, but I would like to see this as buf[sizeof buf - 1] = '\0';

[technobly]

Do these {} make the output exceed 255? Because it would be nice to have a properly formatted JSON object by default.