PSS: Allow pluggable state store configuration to be read from a plan file

[SarahFrench]

This PR follows #37956

Whereas that PR allowed a plan operation to produce a plan file that described a state store, this PR enables apply operations that use a plan file to configure a state store using the data stored in the plan.

This new feature is tested by integration tests and an E2E test that shows the full init-plan-apply workflow when a pluggable state store is in use.

Target Release

1.15.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

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

[radeksimko]

Wouldn't users hit this earlier when producing the plan? 🤔

I'm just trying to understand how realistic it is to have a typo'd state store name inside the plan file and how would users address it.

[SarahFrench]

That's true, this is an artefact of me copy code from elsewhere. I think once we've got most of the init code in place for PSS we'd be able to identify places where we can pull repeated code into reusable methods etc, but the different contexts (from backend state, from config, from plan, etc) might have different needs.

For now I'll remove this from here as I agree it's unlikely to be relevant in the context of a state store from a plan - 50145af

[radeksimko]

Nitpick: Do we actually validate this? 🤔 We can address in a separate PR if not.

[SarahFrench]

There is some validation here:

terraform/internal/configs/state_store.go

Lines 77 to 85 in 578766b

	if provider.AliasRange != nil {
	// This block is in its own namespace in the state_store block; aliases are irrelevant
	return nil, append(diags, &hcl.Diagnostic{
	Severity: hcl.DiagError,
	Summary: "Unexpected provider alias",
	Detail: "Aliases are disallowed in the 'provider' block in the 'state_store' block",
	Subject: provider.AliasRange,
	})
	}

But I think there isn't any test coverage for that - I can make a ticket for that