r/key_vault: defaulting soft_delete_enabled on to match the updated API behaviour

[tombuildsstuff]

This PR updates the azurerm_key_vault resource to match the updated API behaviour rolled out over late last month / the new year. Whilst #10007 provides one solution to this, after extensive testing there was ultimately more necessary to make this work, as such this PR includes:

• Data Source: azurerm_key_vault - deprecating the field soft_delete_enabled (and conditionally removing this should 3.0 mode be enabled)
• Resource: azurerm_key_vault - deprecating the field soft_delete_enabled and defaulting this to true (conditionally removing this should 3.0 mode be enabled). Notably this PR removes the error when attempting to disable/enable this - but since this is hard-coded to true in the Read function, operators can update their configurations (or remove the field) to clear this diff.
• • Resource: azurerm_key_vault - defaulting the field soft_delete_retention_days to 90 days, to match the API behaviour. Notably it's only possible to set this value a single time (either during create, or one-time during update) at which point it's immutable - so a state migration was necessary to default this if not explicitly set - as it's defaulted in the API but not returned unless explicitly configured.

As such this PR supersedes #10007 but fixes #9988 (albeit in a slightly different manner).

[tombuildsstuff]

For the changelog:

BREAKING CHANGES

* `azurerm_key_vault` - the field `soft_delete_enabled` is now defaulted to `true` to match the breaking change in the Azure API where Key Vaults now have Soft Delete enabled by default, which cannot be disabled. This property is now non-functional, defaults to `true` and will be removed in version 3.0 of the Azure Provider. [GH-10088]
* `azurerm_key_vault` - the field `soft_delete_retention_days` is now defaulted to `90` days to match the Azure API behaviour, as the Azure API does not return a value for this field when not explicitly configured, so defaulting this removes a diff with `0`. [GH-10088]

IMPROVEMENTS

* `azurerm_key_vault` - the field `soft_delete_enabled` is now defaulted to `true` to match the Azure API behaviour where Soft Delete is force-enabled and can no longer be disabled. This field is deprecated, can be safely removed from your Terraform Configuration, and will be removed in version 3.0 of the Azure Provider. [GH-10088]

BUG FIXES

* `azurerm_key_vault` - the field `soft_delete_retention_days` is now defaulted to `90` days to match the Azure API behaviour. [GH-10088]

[tombuildsstuff]

Ignoring one failing test in a destroy function due to some recent refactoring (which'll be fixed separately) - the tests pass:

[katbyte]

LGTM 👍

[ghost]

This has been released in version 2.42.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.42.0"
}
# ... other configuration ...

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!