Support setting Terraform provider features

[vrabbi]

What problem are you facing?

We are creating multiple large compositions using this provider, and they all create resource groups with many resources within the RG. we want to be able to set the features section of the terraform provider to allow for bypassing the safety limits created by Azure. the main use case for us is to eanble the feature: prevent_deletion_if_contains_resources under the resource_groups feature key. This would allow for deleting the resource group to also delete all resources in that group. by doing that we can change our management policies to only have delete on the resource group which saves alot of time, and it also helps in covering use cases like AKS clujsters where we want to delete the resource group in order to have all PV backed disks and load balancers deleted automatically for us.
While this specific feature is what we currently need, the ability to set via providerConfig a features block like in terraform would unlock a lot of options.
Currently we have had to go down the approach of using the crosplane terraform provider to create the resource group with that setting and everything else we then do via the azure family providers but this is a slower, suboptimal and more cumbersome solution then we hoped for

[jeanduplessis]

@vrabbi On initial evaluation of this request, enabling this capability would be in violation of the high-fidelity principal of the Crossplane Resource Model: https://github.com/crossplane/crossplane/blob/master/design/one-pager-managed-resource-api-design.md#high-fidelity

Apart from this we are not confident that allowing end-users to modify behavior of the underlying Terraform provider is a good idea, as it could likely result in issues in the code we generate which expects things to work in a specific manner.

[vrabbi]

Wouldnt not enabling the features of the terraform provider for a resource be what is in contradiction to the high fidelity goal for crossplane?

Its unfortunate that the terraform provider doesnt have this setting in the resource itself but i dont see that changing as there are dizens of features using in the providers configuration in the TF provider for many resources.

I get the risk of enabling making changes to the config but at least from an end user perspective this makes it much more likely we will not be able to move to crossplane for azure projects and may need to evaluate other options as so much functionality will be lost for us making it a very difficult choice to go with.

The crossplane terraform provider is not a solution for long term in our case especially at scale, and without this type of functionality we cant move to the crossplane azure provider which is unfortunate

[switchboardOp]

I can't help but agree with @vrabbi. If the underlying provider for this kind of resource is terraform-provider-azurerm then it "...should expose everything that provider exposes to its users as much as possible".

As pointed out there are other reasons to not expose this option, but it seems backwards to say no and justify it by pointing to a principal that aspires to expose every possible knob.