SDK features to help with attributes that apply to many resource types

Terraform 0.11.13

Terraform does not store provider config in the state file or anywhere else, and this makes for a whole host of problems such as:

1. Deleting some of the code base, and associated providers thinking you are deleting resources means that terraform is unable to operate... - it is unable to either refresh or delete the resources which were created with the now-deleted provider in the state file because it no longer has a current working-directory provider definition. This necessitates a two step removal process, and destroy is not clean. "Easy dont delete the provider" I hear you say, but when a module defines a provider more explicitly than just an alias, and you take a module out of usage, which is an entirely legitimate thing to do, you get the same problem for the same reason

2. Changing a provider on a resource leads to terraform not being able to handle if for example you want to swap a resource from one region to another region. Terraform never stored the original provider, so thinks the resource should be where the new provider points - the fact it then cant find it with the new provider means it deletes it from the statefile, and NOT in actuality - resulting in a successful apply, when in fact the original resource is still there potentially costing money, when you dont realise it.

These would all be fixed by storing provider config in the statefile and ensuring that delete operations use the already-stored provider config (from the state file), but create/modify operations use the current working-directory provider config. (possibly with cmdline flags which allow you to choose). Provider config doesnt usually contain any sensitive information, so I dont see there is a problem in doing it.

These are the two biggest working issues I find with terraform refactoring

Start by reviewing how Terraform 0.11.13 currently handles provider configuration and state during resource refresh, deletion, and provider changes. Reproduce the two refactoring scenarios described in the issue, then determine the affected SDK entry points and tests. Done means provider configuration is retained for existing resources and old configuration is used for deletion while current configuration is used for create and modify operations.

Written by the indexing model from the issue text.