Work around uuid file corruption in balenaEngine health check

[lmbarros]

We have detected one more way in which the uuid file used by containerd can get corrupted. This time, the file is not empty, but doesn't contain a valid UUID either.

This commit thus extends the existing workaround to also handle this case.

See https://github.com/balena-os/balena-engine/issues/322

Testing

I tested this manually only. I built balenaOS for raspberrypi3-64 using my branch of meta-balena and flashed it to a device. Then I tried to manually change the contents of the uuid file and run the health check to see the results:

• When changing it to one of the formats accepted by containerd, the healthcheck passed and the uuid file remained unchanged.
• When changing it to an invalid format (including making it an empty file), or removing it altogether, the healthcheck passed and and new, valid uuid file was created.

In other words, no form of bad uuid should not cause the Engine healthcheck to fail after this change.

Regarding automated tests: I believe it should be possible to add some automated test cases for that -- basically automate the kind of manual testing I described above. I am not so sure this would add significant value, though. (FWIW, we don't have automated tests for the current version of this workaround)

---

Contributor checklist

• [ ] Changes have been tested
  • [ ] Covered in automated test suite
  • [ ] Manual test case recorded
• [ ] Change-type present on at least one commit
• [ ] Signed-off-by is present
• [ ] The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

[lmbarros]

@resin-jenkins retest this please

[lmbarros]

@resin-jenkins retest this please

[klutchell]

@resin-jenkins retest this please