feat: replan between execution order groups during apply

[marcosaranda-appspace]

what

Adds an opt-in repo-level setting:

replan_between_execution_order_groups: true

When enabled, a broad atlantis apply will:

1. Apply earlier execution_order_groups with the reviewed planfiles
2. Re-run plan (and policy_check when configured) for later groups
3. Apply those later groups with the refreshed planfiles

Default remains false, so existing plan-then-apply review semantics are unchanged.

why

Fixes #2243. Terragrunt (and similar) stacks plan dependents with mock_outputs while their parents do not exist yet. Atlantis then applies the stale mock planfile for the child after the parent apply. depends_on and execution_order_group only order work; they do not refresh planfiles.

Related: #6106, #6558 (pausing between groups is complementary, not a substitute).

safety and compatibility

• Mid-apply replans set MidApplyReplan, reuse GetWorkingDir, and skip Clone/MergeAgain, so sibling planfiles in the pull workspace are never wiped or invalidated. Plan-stage PR requirements are also skipped, since apply requirements already ran and MergeAgain is intentionally not performed.
• Mid-apply replans set SuppressVCSStatus and SuppressJobOutput, so project commit statuses do not flip to plan mid-apply.
• Mid-apply plan and policy output does not enter apply ProjectResults, so apply PR comments and the apply DB status stay clean.
• If an earlier group fails while the setting is enabled, later groups are skipped rather than refreshed against incomplete dependencies.
• With the setting off, abort_on_execution_order_fail behavior is byte-for-byte the previous behavior, including the shared plan command path.
• Distinct execution_order_group values are recommended. If every project shares group 0 with parallel_apply: true, Atlantis still runs a single wave and cannot replan between projects.

tests

• New unit tests: replan enabled, disabled, replan failure, and earlier-apply-failure stopping later groups.
• New unit test asserting the mid-apply plan uses GetWorkingDir, never Clone/MergeAgain, and skips plan-requirement revalidation.
• Config round-trip test for the new key.
• Whole repository suite green in ghcr.io/runatlantis/testing-env:latest (make test-all && make check-fmt), including server/controllers/events.
• markdownlint-cli2 clean across runatlantis.io/**/*.md, and go vet clean on the touched packages.
• Manual Terraform parent/child reproduction: child planned against a mock id, parent applied, then replan and apply wires the child to the real parent id.

notes for reviewers

• Opt-in only, since maintainers have asked not to change default planfile semantics.
• Mid-apply replan means later groups may apply a plan that was not the exact one commented on the PR. The docs call this out explicitly.
• When all projects share one execution order group and run sequentially, replan only applies to projects that declare depends_on.
• Happy to iterate on naming, or on whether the refreshed plan should pause for human review (which could combine with feat: pause apply between execution order groups #6666).

[pseudomorph]

Hi @marcosaranda-appspace -- Thanks for the submission here. I think something along these lines is needed. But, I'd like to ensure that the ultimate approach aligns with the long-term goals of the project.

Some things that comes to mind is whether to surface the plan delta on re-plan, or if automatically applying the refreshed plan, if there should be any criteria which toggles proceed with auto-apply vs bail and show the plan.

I'll try to find some time to look over this.