Support a dry run mode upgrade of TRE components

Problem

Upgrading the components (workspaces, workspace services, shared services, user resources) of a production TRE carries a significant element of risk, since terraform will destroy and recreate azure resources when certain attributes in the terraform are changed.

This is not a problem (and indeed desired) for stateless resources such as private endpoints or other network components, but the problem manifests when resources are holding user data, e.g. virtual machines, storage accounts.

E.g. azurerm_windows_virtual_machine is destroyed and recreated when any of the following elements are changed:

admin_password, admin_username, additional_unattend_content, availability_set_id, computer_name, custom_data, edge_zone, enable_automatic_updates, eviction_policy, location, max_bid_price, name, os_disk.diff_disk_settings, os_disk.disk_encryption_set_id, os_disk.secure_vm_disk_encryption_set_id, os_disk.security_encryption_type, os_disk.storage_account_type, plan, platform_fault_domain, priority, provision_vm_agent, resource_group_name, secure_boot_enabled, source_image_id, source_image_reference, timezone, vtpm_enabled, winrm_listener, zone

E.g. azurerm_storage_account is destroyed and recreated when any of the following elements are changed:

name, resource_group_name, location, account_tier, account_replication_type, edge_zone, is_hns_enabled, nfsv3_enabled, queue_encryption_key_type, table_encryption_key_type, infrastructure_encryption_enabled, immutability_policy, immutability_policy.state, dns_endpoint_type

It's easy for one of the destructive attributes to change (intentionally or inadvertantly)... or perhaps because of a change in the terraform provider serialisation between versions.

(Potential) Solution

Support a dry run mode for component update/upgrade, which would generate a terraform plan only, and make the plan available for inspection.

While this does not remove the risk entirely, it mitigates it by allowing a TRE administrator to review the TF plan before deciding whether to proceed with the update/upgrade.

Other suggestions/thoughts welcome :-)

Start by tracing the component update/upgrade flow and where Terraform operations are generated for workspaces, workspace services, shared services, and user resources. Done means an upgrade can generate a Terraform plan without applying it and make that plan available for administrator inspection before proceeding.