Allow providers to return post-apply & post-configure warnings

[radeksimko]

Providers today are able to return warnings to the user only via validation functions, which run at plan time.

There are however cases when providers would benefit from having the capability to warn users after the apply operation has finished or after configuration of the provider is done.

Example use cases

1. AzureRM provider does clean up OS/data disks for VM / VM Scale Sets. Failure to finish this is not considered critical during vm deletion, but it's useful to notify user about this.
2. Retrieving Access Keys for Storage Accounts is a privileged operation in AzureRM, it is therefore set to an empty string if user doesn't have permissions. It’d be handy to explain that in an alert.
3. AWS provider has certain logic associated with account IDs which depends on finding the account ID successfully, which is a non-trivial operation separate from initializing the provider & auth itself, hence optional. Some users who run Terraform in such restricted/weird environments that prevents it from finding account ID may not be aware of negative side effects or even the fact that this happens. Warning would be useful in such situation.

Related, but likely parallel to hashicorp/terraform#17267

[paultyng]

Probably easiest to accomplish this via protocol 5 diagnostics.

[bflad]

Example use case: hashicorp/terraform-provider-aws#10417 (comment)

The RDS service allows you delay modifications to databases until the weekly maintenance window by omitting an "apply immediately" flag when updating. Some environments prefer waiting until the maintenance window to stage operations that cause downtime to an acceptable downtime window. It can be surprising the first time Terraform successfully applies a configuration that results in a (temporary) perpetual update difference when this is not set. We note this with a warning in the affected resource documentation however for those unfamiliar with this behavior, it would be nice to have a post-apply warning about this behavior, e.g.

Since `apply_immediately` was not enabled for this resource, the configuration update has been queued in RDS until the next maintenance window. Terraform will continue show these pending updates as a difference on subsequent plans until they are applied by enabling the `apply_immediately` argument or until the maintenance window occurs. Please note that certain update operations will cause downtime. Additional information: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html

[paultyng]

going to merge this to #74 , supporting diagnostics will enable warnings, info, and error messages, and allow providers to specify relevant source location information if applicable.

[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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.