stacks: follow component progress cycle for empty destroys

[DanielMSchmidt]

We expect a component instances to report its plan/apply starting and ending as well as reporting the progress / result. This should also be the case for no-ops like an empty component instance.

Fixes TF-31135

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.

[mildwonkey]

This is nitpicky and you can choose to ignore it, but since I'm fighting with similarly complicated-to-refactor-or-debug tests in actions right now, I'd suggest that you make a new test instead of adding a mode flag.

These tests get harder and harder to work with the more the test harness varies between test cases (or maybe the more the test cases vary within the harness? the more flags we have, is what I'm saying 😂); it's easier to refactor or add new features when tests cover different functionality, instead of all the functions in one test.

I'd peresonally much rather see two tests with names like TestStackChangeProgressDuringPlan, TestStackChangeProgressDuringPlan_destroy than one test that's covering all modes; it's a lot easier to read and understand what's being testing in each individual test that way, and it's easier to debug test failures during development when a single test isn't covering a number of different codepaths.

[nfagerlund]

Awesome! I did an interactive test with a terraform built from this PR branch, and empty destroy applies (from a destroy convergence check) look great:

Likewise with empty destroys due to a deployment being left in the config with destroy = true. This yields good behavior with no changes made to the agent or frontend.

(I don't know why the merge target is set to another PR branch rather than main, but I'm guessing it's on purpose to orchestrate a series of merges or something.)

The base branch was changed.

[DanielMSchmidt]

Good point @nfagerlund, there was no good reason to stack the PRs (pun intended). I at first thought the issue was similar to the other PRs and thus I borrowed some test enhancements. In the end it was not dependent. I moved the related commits to the other PR and kept this one focussed.

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