Fix bug where -backend-config could not override attributes that weren't at the top level in the backend schema

[SarahFrench]

Fixes #36911

The bug reported in that issue is due to how the code that processes -backend-config flags assumes that any key=value pairs passed in are setting values for a top-level attribute in the backend's schema. The error shared in the fixed GH issue arises due to the code looking for a top-level field with the name assume_role.role_arn instead of looking for role_arn nested within assume_role.

terraform/internal/command/init.go

Lines 1036 to 1044 in 474fe47

	attrS := schema.Attributes[name]
	if attrS == nil {
	diags = diags.Append(tfdiags.Sourceless(
	tfdiags.Error,
	"Invalid backend configuration argument",
	fmt.Sprintf("The backend configuration argument %q given on the command line is not expected for the selected backend type.", name),
	))
	continue
	}

To enable testing of this update I needed access to a backend with a schema that matches the s3 backend's use of single nesting. Instead of adding a test that uses the s3 backend and needing to supply credentials, I've updated the inmem backend to optionally have an expanded backend for testing purposes. This is controlled by an environment variable specific to that backend. This could be a first step towards considering making the whole inmem backend not user facing and used 100% for tests.

Target Release

1.13.x

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[dsa0x]

Can we somehow bake this assumption in the code validation?

An input like "test_nesting_single.child.grand" was allowed to pass with no error, and the child value ended up being set.

[SarahFrench]

I've addressed this by swapping to a solution that allows any level of nesting, and that change also addresses issues related to missing parent fields. I figured this was a better approach, as the alternative was to add an error asking users to report issues with overriding fields at a greater level of nesting, and why kick that issue down the road?

Mistakenly approved

[SarahFrench]

Thanks for the review @dsa0x! I think I'll pivot to a different approach so that this doesn't have that assumption about how many levels of nesting are present. But I'm learning more about navigating cty.Values in the process so it'll take a little time

[SarahFrench]

Doing a pivot into investigating #36911 (comment)

Edit: see my comment - I hit an issue with attributes that contain nested attributes that blocks using that project directly. I did like how using that project would reduce the code by a lot though.