cli: enable constellation apply to create new clusters

[daniel-weisse]

Context

The constellation apply command should be the one command to manage a Constellation cluster.
This PR brings the functionality of another command (constellation create) to apply.

Proposed change(s)

• Use the logic of the constellation apply for creating new cluster, replacing constellation create

Additional info

• AB#3288
• e2e test MiniConstellation
  • Unchanged for now, should be adapted to use just constellation apply in the future
  • cli: use apply command to start mini cluster #2551
• e2e test AWS
• e2e test Azure
• e2e test GCP
• e2e self-managed infra GCP
• e2e Terraform module GCP

Checklist

• Update docs
• Add labels (e.g., for changelog category)
• Is PR title adequate for changelog?
• Link to Milestone

[netlify]

✅ Deploy Preview for constellation-docs ready!

Name	Link
🔨 Latest commit	15de42b
🔍 Latest deploy log	https://app.netlify.com/sites/constellation-docs/deploys/655b25634f2bec00088818a0
😎 Deploy Preview	https://deploy-preview-2549--constellation-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[derpsteb]

Lgtm. I am not very familiar with the TF code right now, so I am requesting @elchead as well.

[derpsteb]

Maybe it makes sense at some point to reuse the pattern Adrian introduced in the attestationconfig cli.

It allows unittesting the correct order of operations. And might simplify the apply function. I have sth like this in mind:

type Phase interface {
    func Apply() error
}

func NewPhases(skips map[skipPhase]{}) ([]Phase, error){
	// determine which phases to execute here.
	// call constructor for each phase.
        // don't use reflection, hardcode each constructor call.
}

func main() {
	phases, err := NewPhases(map[skipPhase]{})
	if err != nil {
		log.Fatal(err)
	}
	for _, phase := range phases {
		if err := phase.Apply(); err != nil {
			log.Fatal(err)
		}
	}
}

But I am not sure yet if this is needed. Most phases are just a single command. Imo the main goal would be to separate phase execution from determining which phase to run.

[elchead]

nit: is it just me, but I find this easier to read;
skip suggests we should skip it. (feel free to ignore)

Suggested change

	if !a.flags.skipPhases.contains(skipInitPhase) {
	if !a.flags.skipPhases.skip(skipInitPhase) {

[daniel-weisse]

Updated the docs to remove create.
See the last two commits.

[github-actions]

Coverage report

Package	Old	New	Trend
cli/internal/cloudcmd	69.00%	68.40%	↘️
cli/internal/cmd	53.00%	54.00%	↗️
cli/internal/state	91.90%	94.60%	↗️