Report failures to Azure via Wireserver with KVP Fallback

[peytonr18]

This PR introduces failure reporting for provisioning. The changes ensure that if provisioning fails, the error is reported to Azure either via wireserver or, as a fallback, via KVP .

Key Changes

• XML Payload for Failure Reporting:

  • Implemented build_report_failure_file and report_failure() functions.
  • These functions construct an XML payload similar to cloud‑init, where:
    • <State> is set to "NotReady",
    • <Substatus> is set to "ProvisioningFailed", and
    • <Description> contains a user-visible error message.

• Integration in the Provisioning Flow:

  • In the provision() function, when a provisioning error occurs:
    • The current goalstate is fetched from wireserver.
    • report_failure() is called with the appropriate error description.
    • If the wireserver connection fails and the error can't be posted, the error is logged via tracing::error! as a fallback.

Next Steps

• Open this as a draft PR to gather feedback.
• Add additional unit tests for report_failure() (could use some insight into how best mimic the sever/request dynamic) and further refine the implementation if needed.

Resolves #58.

[peytonr18]

To Do items here:

• Consider pulling report_heatlh specific functionality into helper functions to declutter on_event() -- DONE, refactored into handle_health_event().
• Investigate how to make the "extra" dynamic based on the emitted trace (or, consider if we even need that).
• Once PR Adding Cached VM ID File for Provisioning Lifecycle Management  #164 is merged, acquire vm_id using the function defined in status.rs.

[cjp256]

There is a new endpoint which does not require us to fetch goal state and uses json instead of xml.

sudo curl -X POST -H 'x-ms-guest-agent-name: azure-init/some-version' \
--header 'Content-Type: application/json' \
--data '{
    "state": "NotReady",
    "details": {
        "subStatus":  "ProvisioningFailed",
        "description": "The VM encountered an error during deployment."
    }
}' \
http://168.63.129.16/provisioning/health 

Example provisoning complete report without description
{
    "state": "Ready",
}

Example provisoning failure report
{
    "state": "NotReady",
    "details": {
        "subStatus":  "ProvisioningFailed",
        "description": "The provisioning client has something to report."
    }
}

Example provisioning in-progress report
{
    "state": "NotReady",
    "details": {

        "subStatus":  "Provisioning",
        "description": "The provisioning client has something to report."
    }
}

Response Code	Meaning
201	success
429	too many requests. Rate limted
503	GoalState is not ready yet, try again

We don't have to do it in this PR, but I would like to switch over to the new endpoint to avoid dealing with goalstate.

The one upside to fetching goalstate is getting the container id.