Address async issues w.r.t BDX and error case handling and recovery in the Darwin OTA provider

[nivi-apple]

We have identified a few key issues to be fixed in the OTA provider where we are not correctly handling use cases where a BDX init is not received after a successful query image or if we run into errors after queryImage returns available on the provider side. This github issue covers 3 separate use cases.

Use case 1: BDX init never comes from accessory after receiving a QueryImageResponse - StatusAvailable.
Use case 2: Query Image return StatusAvailable and either PrepareForTransfer or MakeURI fails and we never reset state on the provider.
Use case 3: We never stop polling for Output events after BDX transfer is successful or any error occurs.
Use case 4: We do not check for node id to respond to the correct requestor for queryImage and BDX Init since we only support one OTA requestor but we should handle this correctly. Add checks before responding if the node id matches what we expect

[nivi-apple]

Solutions: Add a timer on the provider after QueryImage is received that should wait for a BDX init to happen within a reasonable amount of time. if it doesn't we reset state and make sure if an Init comes after the timer is expired, we handle that sanely. If any of the API's PrepareForTransfer or MakeURI fails, we need to reset state on the provider. We should also stop the polling timer if BDX transfer is successful or if there are any errors during the BDX transfer.

[nivi-apple]

Looks like we need to make some architectural changes to support - Use case 4: We do not check for node id to respond to the correct requestor for queryImage and BDX Init since we only support one OTA requestor but we should handle this correctly. Add checks before responding if the node id matches what we expect. Moving it into a separate issue - #24739

[nivi-apple]

Use case 5: When we are in a BDX session with a requestor and we receive a query image from another ota requester currently we send a generic failure which doesn't convey the correct status to the accessory. we need to send query image response busy indicating sdk is busy so that the accessory can use the error in a meaningful way and retry again