Backport of core: Internal implementation of the "refresh only" planning mode and "replace" planning option into v0.15

[teamterraform]

Backport

This PR is auto-generated from #28560 to be assessed for backporting due to the inclusion of the label 0.15-backport.

The below text is copied from the body of the original PR.

---

This PR adds the internal handling of what will eventually become the -refresh-only and -replace=ADDR options when creating a plan. There's not yet any UI-level code to activate these two, so for the moment these are just dead code from an end-user perspective, but I want to land these parts first and then iterate separately on how to present the effects of these in the UI, since I expect that'll be a more subjective discussion with more tradeoffs to weigh.

For "refresh only",at the lowest level of abstraction inside the graph nodes themselves this effectively mirrors the existing option to disable refreshing with a new option to disable change-planning, so that either "half" of the process can be disabled. As far as the nodes are concerned it would be possible in principle to disable both, but the higher-level representation of these modes prevents that combination from reaching Terraform Core in practice, because we block activating both "skip refresh" and the refresh-only planning mode at the same time when creating a context.

The force-replace option is ultimately handled inside the NodeAbstractResourceInstance.plan method, in the same place we handle the similar situation of the provider indicating that replacement is needed, and so the rest of the changes here are just to propagate the settings through all of the layers in order to reach that point. The only externally-visible difference in the result between those two situations is the new ActionReason field we added earlier in #28544, which we'll use in a later commit to describe this situation differently when we present the planned changes to the user.

This also introduces a new Mode field for plans which records which mode was active when the plan was created. As with ActionReason in the earlier PR, this is something we'd intentionally excluded so far in fear of it becoming a load-bearing part of the plan/apply process, but our later UI work here will need to include an explanation in the UI for why a refresh-only plan doesn't plan to change anything and so having core report that out, rather than replicating similar logic in the UI layer, again seems preferable to ensure that these will always stay aligned over time as the rules might change. This field is explicitly documented as for presentation only, since the details in the Changes object should always be totally sufficient to correctly execute the apply step: the plan mode just affects what sort of actions Terraform might include in the plan, not how those chosen actions are to be executed.

Since these two changes have some top-level overlap but are otherwise in different parts of the core package, it might be easier to review them on a per-commit basis.

[apparentlymart]

Cherry-picked manually for better commit messages:

• e6b3506
• ccf2c96
• 245ad09

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