Add config option to use zigpy-ota beta channel

[TheJulianJES]

WIP - see "questions" at the bottom

Proposed change

This adds an OTAConfiguration dataclass to allow Home Assistant Core to provide a config option that enables beta updates for the zigpy-ota provider.
ZHA passes this option to zigpy by adding another zigpy-ota provider with the beta channel and override_previous options set (to remove the default stable OTA provider added in zigpy).

If any zigpy-ota provider is specified in YAML config, that takes precedence and this code doesn't add the overriding beta channel OTA provider.

Additional information

To show this option in Home Assistant Core, some changes will be needed there: home-assistant/core@dev...TheJulianJES:core:tjj/zha_zigpy_ota_beta_channel_config

There's also a dev zigpy-ota provider channel that's updated with new images, as soon as a new update/PR is merged, but I don't want to expose that in the UI. It can still be enabled via HA's YAML configuration.yaml, as described here.

Questions

I've only added a use_beta_channel flag to OTAConfiguration. If we make this an enum/str with channels, we could have ZHA pass through more options for zigpy-ota. If we do that, we could always override the default zigpy-ota provider enabled in zigpy. But since we wouldn't allow enabling dev channel support via the ZHA UI, we'd still have to check for dev extra_providers to allow that via YAML. Or should we disable the zigpy-ota provider by default in zigpy and only enable it through ZHA here?

Not sure if I'm fully happy with this, yet..

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.02%. Comparing base (cf2133e) to head (026b3bd).
⚠️ Report is 1 commits behind head on dev.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #617   +/-   ##
=======================================
  Coverage   97.01%   97.02%           
=======================================
  Files          63       63           
  Lines       10569    10579   +10     
=======================================
+ Hits        10254    10264   +10     
  Misses        315      315           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[puddly]

Hmmm, this is definitely a gap in how we tie ZHA and zigpy together 🤔.

With users being able to override OTA providers via YAML, I wonder: maybe we can simplify this by assigning ids to OTA providers and then have ZHA directly access the default-zigpy-ota provider? Overridden ones would have different IDs and wouldn't be touched.

[TheJulianJES]

Yeah, that makes sense. An even simpler idea I had before was passing a generic channel (and application_version) option in the general OTA config from ZHA. The channel could then be used by whichever providers need it to set the default firmware release channel, most likely only the zigpy-ota provider. But technically, the setting set in ZHA could also control the default that other providers with multiple release channels use then, i.e. it's not tied into a specific provider instance like in this PR.

(and application_version would be passed down in a similar way from ZHA with its current version for all (zigpy) providers to possibly use for matching images per min/max ZHA/HA version)

For the OTA channel stuff, I'm also good with your ID idea, so we can go that route.

[puddly]

Passing channel globally works too. Realistically we'll be deprecating all of the OTA providers other than zigpy in the next couple of releases so it won't really matter. We can also change the APIs, since they're only used internally.