Update GKE Nodes to have optional Workload config

What does this MR do?

MR switches workload_metadata_config config in GCP Kubernetes node pools to be dynamic.

This is required as GCP will set this to a third value - GCE_METADATA when workload is not configured. Our current design is to always set to either MODE_UNSPECIFIED or GKE_WORKLOAD so this causes changes to be made every TF run:

  # module.gitlab_ref_arch_gcp.google_container_node_pool.gitlab_supporting_pool[0] will be updated in-place
  ~ resource "google_container_node_pool" "gitlab_supporting_pool" {
      ~ node_config {
            tags              = []
            # (12 unchanged attributes hidden)


          ~ workload_metadata_config {
              ~ mode          = "GCE_METADATA" -> "MODE_UNSPECIFIED"
                # (1 unchanged attribute hidden)
            }
            # (1 unchanged block hidden)
        }

        # (3 unchanged blocks hidden)
    }

We're effectively fighting a system value here that we need to avoid - After the change is applied GCP sets it back.

Related issues

Relates https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/14727 !485 (merged)

Author's checklist

When ready for review, the Author applies the workflowready for review label and mention @gl-quality/get-maintainers:

• Merge request:
  • Corresponding Issue raised and reviewed by the GET maintainers team.
  • Merge Request Title and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline
• Code:
  • Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.).
  • Documentation created/updated in the same MR.
  • If this MR adds an optional configuration - check that all permutations continue to work.
  • For Terraform changes: setup a previous version environment, then run a terraform plan with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
• Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Quality Enablement team if unsure.