PSS: Allow pluggable state store configuration to be stored in a plan file and used during an apply operation

[SarahFrench]

Context

The process of how data gets into a planfile created by a plan command is a little convoluted, so here is a diagram attempting to explain how it works. Note that the diagram explains how it works after the changes of this PR, so describes parallel backend- and state store-related fields in places, but broadly the sequence of events is unchanged.

This PR

Follow up to #37246, which began implementing use of pluggable state stores with planfiles.

This PR:

• Fixes the work from the previous PR: Update data stored in plan files to enable using PSS with saved plans #37246 didn't include storage of the provider's config in the plan file.
  • 5bbd3ae
• Allows users to save state store config to a planfile during plan and use that in an apply command:
  • Allow data to enter the plan file during plan: d90b7a0
    • The Meta now has a field stateStoreConfigState
    • When Operations are assembled they can set a new PlanOutStateStore field with a description of the state store's config.
    • That new PlanOutStateStore field can be used when writing the plan file
  • Implements initialising a state store from a planfile: 944d3a0

These new features are tested via new integration tests in:

• internal/backend/local/backend_plan_test.go
• internal/command/apply_test.go
• internal/command/plan_test.go

And a new E2E test covering the full init-plan-apply workflow in internal/command/e2etest/primary_test.go

Target Release

N/A

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.

[SarahFrench]

Opening for review, as I don't think there are any easy ways to break this PR off into smaller PRs any more. I hope that the diagram in the PR description helps to make review more approachable, but I'm happy to do a synchronous discussion via Teams too.

After some time away from this, I think an obvious split is plan/apply, duh! I'll open a PR that has just the writing data into a plan, and then the stacked PR will be reading from the plan, and E2E tests.

[SarahFrench]

PR split into:
#37956
#37957

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.