Fix remote state consumers compatibility for Terraform Enterprise

[chrisarcand]

Description

In v0.25.0, a regression was introduced when adding the new remote state consumers feature. Unlike other relationships in the provider - which are serialized in the same original resource document - remote state consumers on a workspace only exist at a separate endpoint which must be read. When the endpoint can't be read in the case of a preexisting Terraform Enterprise installation without the feature, it causes a failure when doing anything with the tfe_workspace resource.

An ideal scenario would be for a version check to determine whether a call should be made - but the current tooling here is minimal. Instead, we apply the following heuristic to make it backwards compatible for TFE:

If a call to the remote state consumers endpoint fails and is a 404 Not Found, assume that the only plausible reason for it is an old TFE installation: ignore it entirely and set the computed global_remote_state attribute to an implicit 'true' value (which indicates the old behavior which is not configurable until you upgrade your Terraform Enterprise installation). This is reasonable because having reached that point, the primary call to read the workspace succeeded, meaning you are authorized to the workspace and the likelihood of the remote state consumers call failing from a Not Found error for any other reason is exceedingly small.

Note this proposes a change from what was indicated in de8f3fa (requiring TFE v20210401 to use >=0.25.x of this provider), instead making the change backwards compatible as a bugfix.

Testing plan

Do all of the following with any released Terraform Enterprise version:

1. Apply the following configuration using 0.24.0 of the provider. This are just pretest conditions; you're creating a workspace that simulates an existing workspace in an older TFE before 'upgrading' to the proposed changes.

provider "tfe" {
  hostname = "your.tfe.host"
  token = var.provider_token
}

variable "provider_token" {
  type = string
}

resource "tfe_workspace" "preexisting_workspace" {
    name                  = "workspace-from-older-tfe"
    organization          = "your-org"
}

2. Now, build this branch and do an override to use it.
3. Change the configuration like this:

provider "tfe" {
  hostname = "your.tfe.host"
  token = var.provider_token
}

variable "provider_token" {
  type = string
}

resource "tfe_workspace" "preexisting_workspace" {
    name                  = "workspace-from-older-tfe"
    organization          = "your-org"
}

resource "tfe_workspace" "new_workspace" {
    name                  = "new-workspace-from-older-tfe"
    organization          = "your-org"
}

4. Start an apply. In the plan, the only changes should be the new workspace you added (no change to the existing workspace).
5. In addition, the new workspace plan should include global_remote_state = (known after apply).
6. Apply it. Running terraform plan after that should result in a happy empty plan.
7. Check your state - global_remote_state for both the workspaces should be true.
8. Add global_remote_state = true to one of the workspaces. Plan it. Should be an empty, no-op plan.
9. Now change global_remote_state = false. Apply it. This will succeed, but be ignored - a plan afterward should again try to suggest to change it to true. This is expected behavior. You cannot change the behavior of this (faux) attribute in TFE < v20210401.

Before continuing, "upgrade" your Terraform Enterprise installation to the v202104-1 release. (For external contributors: Note that as of this writing, this Terraform Enterprise version has not yet been released).

10. Do a terraform plan. This should result in an empty, happy plan.
11. Use the remote state consumers features as normal and indicated in the documentation. Should work!

[lafentres]

I'm not sure what the best way to handle this is but I do think indicating that version 0.25.0 isn't compatible with versions of TFE earlier that v20210401 is still useful information. Maybe keeping the changelog the way it was and/or indicating something that explains the bug more in-depth in 0.25.1? Or maybe just adding a notes section to 0.25.1 that explains what the regression was? It seems like something like that might be helpful.

[chrisarcand]

@lafentres Ah yeah, good point, we should make that CHANGELOG entry a little louder.