configs/configschema: Introduce the NestingGroup mode for blocks

[apparentlymart]

In study of existing providers we've found a pattern we weren't previously accounting for of using a nested block type to represent a group of arguments that relate to a particular feature that is always enabled but where it improves configuration readability to group all of its settings together in a nested block.

The existing NestingSingle is not a good fit for this because it is designed under the assumption that the presence or absence of the block has some significance in enabling or disabling the relevant feature, and so for these always-active cases we'd generate a misleading plan where the settings for the feature appear totally absent, rather than showing the default values that will be selected.

NestingGroup is, therefore, a slight variation of NestingSingle where presence vs. absence of the block is not distinguishable (it's never null) and instead its contents are treated as unset when the block is absent. This then in turn causes any default values associated with the nested arguments to be honored and displayed in the plan whenever the block is not explicitly configured.

The current SDK cannot activate this mode, but that's okay because its "legacy type system" opt-out flag allows it to force a block to be processed in this way anyway.

---

I didn't want to add this in right now, but I couldn't think of a reasonable way to defer adding it without requiring a breaking change later. Therefore I've tested this carefully with both some tests shown in the changeset here and with a special test provider (not using the current SDK) that allowed me to exercise this feature in a more open-ended way. One result of that open-ended testing is shown in the following screenshot:

In this test resource type, the access block was defined as NestingGroup and then I ran terraform apply with no explicit block present in configuration. With NestingSingle we would've seen no mention of that block in the plan at all, but now with NestingGroup we can see the default block fully expanded with the default policy value of {}.

This will be essentially dead code in real-world use for the time being, until we release an updated SDK with support for activating this mode. But having the mechanisms in place to deal with it now means it should be safe to release that SDK later without making a breaking change to the plugin protocol.

The diff seems large because I visited every usage of configschema.NestingSingle to determine what would be the suitable behavior for configschema.NestingGroup in that scenario. In many cases, we treat it as equivalent to NestingSingle because the main handling of the NestingGroup behavior happens at decode time.

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