Complete end-to-end TLS support for AMT provisioning

[graikhel-intel]

Description

This is a follow-up to the existing end-to-end TLS work. The goal of this story is to address the remaining gaps and ensure TLS is consistently enforced across provisioning and post-provisioning flows.

Currently, on AMT 15 and below, If a device was previously configured in ACM or CCM using non-TLS, and is later reconfigured using -tls-tunnel, RPS does not set up the certificates or perform port switching. As a result, communication continues over non-TLS instead of switching to TLS.

Scope

• Ensure RPS correctly configures TLS when switching from non-TLS to -tls-tunnel flows, especially for AMT 15 and below.
• Validate TLS certificate during both pre-provisioning** and post-provisioning stages when amt_tls_reject_unauthorized=true in RPS.
• On AMT 16 and above, replace the default AMT certificate used post-provisioning with the DMT TLS certificate.
• Minor UX/message updates:
  • On AMT 19 and above: message shows "Upgrade to Admin Control Mode"
  • On AMT 15 and below: message shows "Admin Control Mode"
• Improve debugging:
  • rpc -v should print both request and response in XML (instead of response being base64)

Acceptance Criteria

• TLS is correctly configured when transitioning from non-TLS to -tls-tunnel, including AMT 15 and below scenarios.
• TLS certificate validation works for both pre and post provisioning.
• On AMT 16+, default certificate is replaced with DMT TLS certificate after provisioning.
• rpc -v prints both request and response in XML format.