ResourceIdentity: Validate that identities do not change after Terraform stores it

[austinvalle]

This PR re-introduces the validation that previously lived in Terraform core (removed in hashicorp/terraform#36989), which ensures that resource identities do not change after Terraform core stores them in state.

The one tricky part of this PR is ReadResource, which the protocol currently does not have sufficient information for us to determine if the state we are refreshing has already been stored (typical use-case) or if we are importing the resource. Rather than loosening how strict the validation is, I added a temporary key to a framework reserved private field, which Terraform passes between ImportResourceState -> ReadResource. Once we've read that field, we can skip validation of the identity, clear the private field, then following refreshes will validate as normal.

As we have the immutable validation in the SDK now, we can allow resources (such as RDS instances) to easily opt-out of that validation when necessary.

There are some corner tests over here which display the immutable error messaging: hashicorp/terraform-provider-corner#340

[rainkwan]

Makes sense to handle the problem of changing identities this way and have the SDK help out with validating the identity/or not when we need to.

[ansgarm]

[SBGoods]

LGTM 👍🏾
I don't know if we want to add a note in the private state documentation about the reserved key, since it's highly unlikely that someone would accidentally use that key name. Maybe if we do something like this again, we can add a section about reserved key names.

[austinvalle]

... I don't know if we want to add a note in the private state documentation about the reserved key, since it's highly unlikely that someone would accidentally use that key name. Maybe if we do something like this again, we can add a section about reserved key names.

We're actually already covered because the framework already validates that the . prefix is off-limits 😌
https://developer.hashicorp.com/terraform/plugin/framework/resources/private-state#reserved-keys

SDKv2 doesn't have any documentation about private, but luckily it's blocked from direct usage, and the indirect usage we have control over (timeouts)