Check if there is a software update available using DCL software update
information.

The OTA provider downloads the updates and prepares them so Matter
devices can consume them.

Use the OTA Provider example app to implement a OTA provider. The
example app supports a JSON update descriptor file to manage update
metadata. Tested with the OTA Requestor app.

Start and commission OTA Provider App when necessary. Use random
discriminator and passcode. Store the Node ID of the OTA Provider
App once setup for fast re-use.

Verify that the DCL software update is indeed applicable to the
currently software running on the device. Add test coverage as
well.

Add global check for update where we can insert hardcoded updates or
updates from other sources in the future.

Make check_node_update a separate WebSocket command which only
checks for updates. The update_node command then will download
and actually apply the update.

Add Update specific exceptions and raise them where appropriate.

Add capability to verify the checksum of the OTA file while
downloading it.

Add two new client commands to check for updates and trigger the
update.

Create log files for each OTA Provider run. Improve setup and
commissioning of the OTA Provider.

Most update logic is related to the external OTA provider (like
commissioning and configuring it). This commit moves most of the
update logic into the ExternalOtaProvider class.

Make use of the new ChipDeviceControllerWrapper to communicate with
the device directly. This avoids unnecessary node interviewing and
showing up on the controller side.

Support updating to a specific software version by string. This requires
fetching all versions one by one, but is much more user friendly. The
code still checks that all restrictions are met (min/max version, etc).

Instead of trying to reuse the same OTA Provider instance for multiple
OTA requests, create a new instance for each request. This is easier
to implement and also allows parallel updates.

Because the OTA Provider is now ephemeral, we need to commission it on
every update. But this is quick and reliable, so not a big deal.

To support multiple updates at once, we need to make sure the OTA
Providers use a distinct Matter port (hence passing 0) and distinct
node ids. The current implementation simply uses the target node id
plus a fixed offset. Since a single node can only run one update at a
time, this is sufficient.

Furthermore, some updates seem to have a difference in reported
versionNumberString value in the DCL vs. what is actually in the OTA
metadata. Specifically Eve updates from the Testnet DCL are such
updates (e.g. 3.2.0 vs 3.2.6705). When using the OTA Provider with the
--otaImageList option, this discrepancy is an issue and causes OTA
Provider to abort.

Using the single OTA update per OTA Provider instance allows us to use
--filepath, which doesn't check the versionNumberString.

When the node's UpdateStateEnum changes from Querying to Idle it
means the update file did not get processed. This could be due to
temporary network issues or the update file not being honored by the
target node.

Instead of using an Event use a Future to mark completion of the update.
This allows to set an Exception in case we see update state transitions
which are unexpected (specifically kQuerying -> kIdle).

Running multiple updates on the same node doesn't make sense. This
should be mostly handled by the client/UX. But we do check on server
side for the critical path.

Don't raise an exception when there is no software version info on DCL.
It is perfectly fine to operate such nodes. An informational message is
good enough for this case.

Use a new model MatterSoftwareVersion to store the software version
information typically fetched from DCL for the Matter nodes.

We've added new commands, so a schema version bump is needed.

Co-authored-by: Marcel van der Veldt <[email protected]>