do not merge: Show that planning for one workspace, switching, and then applying the plan in the wrong workspace doesn't fail

[SarahFrench]

Context

This:

terraform/internal/command/meta_backend.go

Lines 330 to 332 in 64015ca

	// The current workspace name is also stored as part of the plan, and so this
	// method will check that it matches the currently-selected workspace name
	// and produce error diagnostics if not.

Currently isn't the case.

Bug description

Assume that a plan was raised against workspace A and a user tries to apply it against workspace B.

The actual behaviour varies depending on the type of plan and what state already exists for workspace B.

1. If the plan is create-only, starting from a position of empty state, and workspace B has no state yet then the apply will complete successfully
2. If the plan is create-only, starting from a position of empty state, and workspace B has a prior state then the apply will fail with error Saved plan is stale.
3. If the plan is changing existing resources, i.e. planned using prior state in workspace A, and workspace B has no prior state then the apply will fail with a different state lineage error.

In case 2 & 3 the apply stops before making any changes to state, however the error messages don't clearly point out that mismatched workspaces are the underlying cause.

In case 1 users will find that the new state file is persisted in a different location than they expected. The output from the apply command doesn't say which workspace the apply affected, so the user might not notice the issue immediately.

In this PR:

• Case 1 is illustrated with TestPrimarySeparatePlan_incorrectWorkspace_noPriorState
• Case 2 is illustrated with TestPrimarySeparatePlan_incorrectWorkspace_withPriorState
• Case 3 is illustrated with TestPrimarySeparatePlan_incorrectWorkspace_planChangingExistingResources_noPriorState

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]

Commit b3d6694 shows the 3 tests passing, as they define current behaviour.

Commit 4391675 shows the tests failing, as after changes in BackendForLocalPlan there is an earlier error returned that reports the workspace mismatch between the working directory and the plan.

[SarahFrench]

Closing this PR as it's just for illustrative purposes currently. I wasn't intending to merge these E2E tests.