Consider InternalValidate equivalent

[kmoe]

The Provider.InternalValidate() and Resource.InternalValidate() (which calls schemaMap.InternalValidate(), Importer.InternalValidate()) exported functions in terraform-plugin-sdk provide a way for callers to validate that, for example:

• Optional and Required cannot both be set on the same attribute
• If a resource has no Update, all Computed attributes must be ForceNew
• State upgraders must cover all appropriate schema versions
• Context-aware CRUD functions and their non-context-aware equivalents cannot both be set

While many of these do not apply to terraform-plugin-framework, we should consider whether an equivalent function is appropriate.

The InternalValidate equivalent(s) could validate that:

• PlanModifiers are not set on data sources (see #102)

Alternatively, we can declare a user-run internal validation function an anti-pattern, in which case this issue should be closed and the above validation done through other means.

[Brian Flad]

#157 has an example use case that this theoretical functionality could also check that configuration validation fields are not defined on schemas with no configurable attributes.

[Brian Flad]

At this juncture, I'm inclined to recommend that we implement any remaining validations to get returned as error diagnostics as part of the GetProviderSchema response. This will ensure that the provider will not work appropriately in acceptance testing and production, should there be correctness issues. For stylistic issues or coding recommendations, external tooling can be created.

[github-actions]

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.