helper/schema: ConfigMode field in *Schema

[apparentlymart]

This allows a provider developer slightly more control over how an SDK schema is mapped into the Terraform configuration language, overriding some default assumptions.

ConfigMode overrides the default assumption that a schema with an Elem of type *Resource is to be mapped to configuration as a nested block, allowing mapping as an attribute containing an object type instead.

This should rarely be needed, but it can be useful in situations where the provider was assuming attribute-like behaviors in 0.11 (such as ability to explicitly assign an empty list) which were possible because 0.11 didn't enforce the use of block syntax for nested resources. For some real examples, see #20505.

Since this uses the attribute syntax, this'll work best for SDK schema attributes that already had plural names, suggesting that they were representing a single attribute containing multiple objects:

  thingies = [
    {
      foo = "bar"
    },
  ]

  thingies = []

Back-compatibility with Terraform 0.11 may require this to be used with singular-named attributes in situations where prevailing usage was inconsistent about whether a particular name was an attribute or a block, which is less-ideal but can be used in a pinch to avoid or defer a breaking change:

  thingy = [
    {
      foo = "bar"
    },
    {
      baz = "boop"
    },
  ]

Along with the explicit forcing of attribute mode in config, this also includes an implicit rule that Computed-only (that is, not also Optional) attributes are always represented as attributes, since it is confusing and strange to use the configuration-only idea of nested block syntax for an attribute that can't be specified in configuration anyway. This results in better UX in the terraform plan output because the exact structure of the result can be shown, rather than confusing the user by showing the result as a nested block diff when no such nested block was present.

These behaviors only apply when a provider is being used with Terraform v0.12 or later. They are ignored altogether in Terraform v0.11 mode, since attribute vs. block syntax is not enforced in v0.11 anyway. We are adding this primarily to allow the v0.12 version of a resource type schema to be specified to match the prevailing usage of it in existing configurations, in situations where the default mapping to v0.12 concepts is not appropriate.

This is split into two commits because the first commit will need to be cherry-picked onto the v0.11 branch to enable the downgrade-and-acctest regression testing strategy for ensuring that provider logic continues to behave correctly with v0.11 as future changes are made. I will do that as soon as this is merged, so approval of this PR also implies approval to place the first commit on the v0.11 branch (just to avoid a pointness second review round-trip.)

[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.