Add Terraform 0.12 support

[rifelpet]

This adds support for HCL2 via a FeatureFlag (default: enabled)

The feature flag name is Terraform-0.12 but I'm find with using something else if people prefer.

• kops update cluster --target terraform will now create .tf files in Terraform 0.12 syntax.
• KOPS_FEATURE_FLAG=-Terraform-0.12 kops update cluster --target terraform will need to be used to preserve the old behavior.

The git changes in tests/integration/update_cluster demonstrate how the .tf file will change.

I've updated the ./hack/verify-terraform.sh script to now validate .tf files with Terraform 0.12 by default and the syntax passes validation. The Google provider does report an error regarding a missing machine_type but that is independent of this PR (before this PR the GCE Terraform output wouldn't even work with Terraform 0.11 because of a version requirement conflict. Kops required Google Terraform provider >= 3.0 but 3.0 requires Terraform 0.12)

HCL2 uses the go-cty dynamic type library which is why the additional field tags are added to every Terraform struct in the tasks packages.

The HCL library doesn't support writing some of the syntax easily, so much of upup/pkg/fi/cloudup/terraform/hcl2.go implements byte-level functionality for what Kops needs. See hashicorp/hcl#347 and hashicorp/hcl#356 for examples and discussion around those limitations.

closes #7052

[schollii]

Until an official version of kops contains the above PR merged, are we stuck with using TF 0.11? E.g. can we use latest official kops 1.17 with terraform 0.12: kops will generate HCL rather than HCL2 but I think terraform 0.12 should be able to handle HCL generated by kops, has anyone tried? I'm asking here rather than hashicorp github because the answer depends not just on the official TF 0.12 support for HCL, but also on HCL that kops generates, is it fully compliant etc. One of my colleagues was having issues with the kubernetes.tf file generated.

[rifelpet]

it looks like google_compute_instance_template isn't getting rendered properly. My guess is because it uses type embedding, i'll investigate further.

kops/upup/pkg/fi/cloudup/gcetasks/instancetemplate.go

Lines 419 to 422 in 3344ff4

	type terraformInstanceTemplate struct {
	terraformInstanceCommon
	NamePrefix string `json:"name_prefix"`
	}

/hold

[justinsb]

I think we can merge this, and we can look at the terraform breakage in a follow on, if it's confined to that one special case. Worst case we just expand out the struct (or write our own tf12 renderer, now that the format is a little more reasonable?)

I verified that we didn't break tf11 output by stopping at the intermediate stage and verifying that the tests still passed.

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, rifelpet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justinsb,rifelpet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rifelpet]

ok, I'm fine with that. If we dont fix GCE before the next release we can always instruct GCE users to revert back to the old behavior via feature flag. I'll try to look into it soon though

/hold cancel