Pass isEnabled to Porter bundles as is_enabled parameter on disable/enable

[Copilot]

Disabling a resource via the TRE API only set a flag in the database — isEnabled was never forwarded to the Porter bundle, so Terraform had no mechanism to stop, deallocate, or remove Azure resources on disable.

What is being addressed

When a workspace, workspace service, or user resource is disabled, the upgrade action is sent to the resource processor but the bundle receives no signal that the resource is being disabled. Bundle authors have no way to conditionally manage Azure resource lifecycle (e.g. delete a VM but keep its disks, or stop a web app to avoid costs).

How is this addressed

• api_app/models/domain/resource.py: Added "isEnabled": self.isEnabled to get_resource_request_message_payload() so every Service Bus message carries the current enabled state.

• resource_processor/helpers/commands.py: Added is_enabled to get_special_porter_param_value(), mapping it to msg_body["isEnabled"] — consistent with how workspace_id, parent_service_id, and owner_id are already resolved from the message body.

• docs/tre-workspace-authors/authoring-workspace-templates.md: Added a "Handling resource enable/disable" section documenting the is_enabled parameter convention and a porter.yaml usage example.

Bundle authors opt in by declaring is_enabled in porter.yaml and passing it into Terraform:

parameters:
  - name: is_enabled
    type: boolean
    default: true
    description: "When false, cost-incurring Azure resources should be stopped or deleted."

The decision of what to do (delete VM but keep disks, stop a web app, etc.) is intentionally left to each bundle's Terraform, as discussed in the issue.

[rudolphjacksonm]

@copilot bump API versions

[Copilot]

@copilot bump API versions

Done — bumped api_app from 0.25.15 → 0.25.16 and resource_processor from 0.13.3 → 0.13.4, with a CHANGELOG entry in the Unreleased section. Commit: bcd09d8 → latest.

[JC-wk]

Might be good to implement this in one or multiple of the existing templates so it can be properly tested. A common approach / guidance on what disabling should actually do would be helpful. E.g powering off VMs, deallocating resources? I expect it has to be reversible so no data destruction, but it should also disable access to the resource (e.g nsg/firewall rules etc?)