fix(azure-aks-multicluster): stop managing global DCF enable, document as prereq

[cmchenr]

Description

The network layer of this blueprint applied aviatrix_distributed_firewalling_config.enable directly, which toggles Distributed Cloud Firewall on for the entire controller, not just this blueprint's resources.

DCF's enable state is a controller-wide singleton. On a controller shared by multiple blueprints/tenants, this causes two problems:

• Apply-time contention: multiple Terraform configs fighting over the same global setting.
• Destroy-time blast radius: terraform destroy on this blueprint attempts to disable DCF globally, which can fail (AVXERR-DFW-0008) if other tenants have active DCF policies, or worse, succeed and silently break every other blueprint's DCF enforcement on that controller.

This PR removes the resource (and its now-stray depends_on reference in aviatrix_dcf_ruleset.aks_demo) and documents enabling DCF as a one-time, out-of-band prerequisite in the README's Prerequisites table — consistent with how other controller-wide singletons (account onboarding, etc.) are already treated as prerequisites rather than blueprint-managed resources.

Type of Change

• New blueprint
• Blueprint enhancement
• Bug fix
• Documentation update
• CI/CD improvement
• Other (describe):

Blueprint Checklist (for new or modified blueprints)

Documentation

• README.md includes all required sections (see Blueprint Standards)
• All variables are documented with descriptions
• Architecture diagram is included and accurate — n/a, no architecture change
• terraform.tfvars.example includes all required variables — n/a, no new variables
• Test scenarios are documented — n/a, no new test scenario needed
• Troubleshooting/Prerequisites section covers this change

Code Quality

• terraform fmt passes
• terraform validate passes
• No hardcoded values (use variables)
• Sensitive variables marked as sensitive = true — unaffected
• Resource naming uses var.name_prefix — unaffected

Testing

• Full deploy/destroy cycle tested — not re-run for this change; verified via terraform fmt/validate only (this is a resource removal + doc change, no new resources)
• All test scenarios verified — unaffected
• Tested on documented Control Plane version(s)
• Cleanup leaves no orphaned resources — removing this resource from state on an existing deployment will not re-disable DCF (Terraform state rm semantics); see note below for existing users

Catalog Update

• Blueprint added to catalog in root README.md — n/a, not a new blueprint

Control Plane Version Tested

• Control Plane version: N/A for this change (config-only; validated with terraform validate against provider ~> 8.2)

Cloud Environment

• Cloud provider(s): Azure
• Region(s) tested: N/A for this change

Additional Notes

For users who already applied this blueprint before this change: on your next terraform apply, Terraform will propose to destroy aviatrix_distributed_firewalling_config.enable. Since DCF's enable state is idempotent and controller-wide, allowing that destroy is safe and will not disable DCF as long as any other config/blueprint on the controller still has DCF-dependent resources (it only removes this blueprint's management of the setting, not the setting itself, unless nothing else references it). If you want to be extra cautious, run terraform state rm aviatrix_distributed_firewalling_config.enable instead of letting apply destroy it.

🤖 Generated with Claude Code