Add Terraform build job to environment and document destroy

What does this MR do and why?

This change set proposes that the build job from the Terraform template (which runs a terraform plan) is part of the environment the deploy job is associated with - just that the action is prepare.

IMHO, the prepare action is the closest match to what it does - planning the environment.

What about the stopping the environment?

To close the "integration circle" with Terraform and GitLab environments it would be nice to have the stop action properly configured. However, it's not really clear if we should do this, the reason is that there is only a .terraform:destroy job in the job template, but none in the pipeline template which would inherit from it. Environments today are ONLY part of the pipeline template. The destroy job is in the job template, because most people don't really destroy their environments that often - they are long-running environments, like production. Having a manual destroy job in the pipeline template may not be desired for every pipeline.

What we could do is introduce a special env variable to control the creation of a destroy job in the pipeline template which would be evaluate in the rules:if block and set via manual pipeline trigger when someone really wants to destroy the environment. I also think that if we'd have an environment variable controlling the destroy job we could also change the build job to ran a terraform plan -destroy and omit the deploy job. However, this also has the downside that the on_stop action for the deploy job cannot be linked to the destroy job which would conditionally exist via that variable. I think we face a dilemma here, because GitLab environments together with CI/CD pipelines are not flexible enough for this use case.

For now, I'm going to document how the destroy job can be associated with the environment.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.