Allow cleanup of states that depend on prior runs outputs

[dsa0x]

The important changes here

• The config inspection of skip_cleanup is now done in the config file
  • This led to some minor test changes
• The cleanup nodes are now in a subgraph, so that we are not adding weird dynamic nodes and complicated edges into the graph.
• After a destroy, we only update the in-memory state resources, and we leave the outputs
• We now always write the state outputs to file, even after a destroy of resources. This way, if a run1 state's resources has been destroyed by a later run run3, run2 which references run1 can still access the output values, and use as input to its operations.

Target Release

1.13.x

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[liamcervante]

I think we also want to update the normal cleanup operation as well right? If a run block fails to get destroyed, any dependent run blocks that have different state should not be destroyed as we might need the outputs from that state file?

[dsa0x]

I think we also want to update the normal cleanup operation as well right? If a run block fails to get destroyed, any dependent run blocks that have different state should not be destroyed as we might need the outputs from that state file?

@liamcervante this would be a change in behavior though. It would imply that a state clean up failing prevents other states from being cleaned up. But you are right, it might be necessary, in order to appropriately cleanup that failed state.

[liamcervante]

Yes, I think it's required though - we need to keep dependent states in place otherwise the cleanup command just can't work. There's no breaking changes so I think its fine. The existing behaviour is just "do nothing", so this change being introduced alongside the state manifest file means the user is being left with a lot more information now.

[dsa0x]

The important changes here

• The config inspection of skip_cleanup is now done in the config file
  • This led to some minor test changes
• The cleanup nodes are now in a subgraph, so that we are not adding weird dynamic nodes and complicated edges into the graph.
• After a destroy, we only update the in-memory state resources, and we leave the outputs
• We now always write the state outputs to file, even after a destroy of resources. This way, if a run1 state's resources has been destroyed by a later run run3, run2 which references run1 can still access the output values, and use as input to its operations.