Extend USB/OTA max application update testing

[scott-brust]

Problem

Various users have encountered issues updating large applications. We should extend our testing to cover more realistic use cases.

Solution

The USB and OTA update tests should cover the following scenarios

• OTA small -> large uncompressed
• OTA small -> large compressed
• USB small -> large uncompressed
• USB small -> large compressed
• OTA small -> large uncompressed, with "busy" system
• USB small -> large uncompressed, with "busy" system

The "busy" test do the following

• Start a high priority thread (OS_THREAD_PRIORITY_CRITICAL)
  • This thread does a busy loop and then delay(1) to emulate frequent schedule switches
• Start a normal priority thread
  • This thread does BLE scanning every 500ms
  • Wifi scanning every 15 seconds
• The application loop will delay a random period up to 500ms each time it runs
• USB serial logging will print the firmware update progress. (this only has an impact if USB serial is connected)

Steps to Test

Which unit/integration/application tests are applicable to this code change? (At minimum a test of some kind should be provided)

Example App

Update device-os-test to latest
Build + flash deviceOS@develop
Build test app

device-os-test --test-dir ~/develop/device-os/user/tests/integration/ --device-os-dir ~/develop/device-os/ build msom ota/min_max_app_size -v -- -fixture

Flash + run test app

device-os-test --test-dir ~/develop/device-os/user/tests/integration/ --device-os-dir ~/develop/device-os/ run msom ota/min_max_app_size -v -- -fixture

[avtolstoy]

Just a TODO for future: for cellular + wifi devices on HIL we are not using WiFi for connectivity. Ideally we should do something about that at some point, but for now P2 should cover the case of OTA + WiFi + BLE probably.

[scott-brust]

https://app.shortcut.com/particle/story/126152/add-stress-tests-for-wifi-ble-at-m-som-level