* Update comments to distinguish between operations and state-storage backends more clearly
* Rename `BackendOpts` field `Config` to more specific `BackendConfig`
When key-value tags are enabled and used in the workspace, users may
define the tags attribute as a map of strings in the cloud block in order
to more precicely match workspaces using those tags.
- The cloud plugin wants a go-tfe client to get stuff from TFC.
- Terraform knows how to find all the info you need in order to configure a
go-tfe client, but it's sometimes scattered across configs and env vars and
credentials helpers, and trying to re-implement the resolution logic identically
in another codebase would be error-prone.
- Therefore, it'd be best if Terraform did that resolution and just passed the
plugin all the config info it needs.
There are two options for that handoff:
1. Adding it as an additional argument to the primary Execute RPC interface.
2. Passing it as gRPC metadata, which is a pile of arbitrary key => list-of-strings
pairs transmitted via HTTP/2 headers.
The crux of the decision here is whether a proliferation of plugin protocol
versions whenever we need to add more config data is better or worse than a
fuzzy and typeless key/value bag.
This PR is an implementation of option 2, for discussion and evaluation. (And
after all, this is considered an experimental feature anyway.) It assembles the
necessary information, translates it to the required metadata format, and
attaches it to the request at the proper moment to get everything over to the
plugin.
As previous commits foreshadowed, we're leaning on the existing logic in the
Cloud backend for pretty much all of this.
The plugin needs some config info in order to actually build a go-tfe client and
_do_ anything, and the Cloud backend is the one place that already knows how to
look up and reconcile all the possible sources of that info. So, we'll just find
a Cloud backend and pick its pockets.
This also replaces our reimplementations of hostname lookup and service
discovery, using work the Cloud backend already did.
Currently, Terraform will only run properly signed versions of the experimental
cloud plugin that were downloaded from a TFC instance that provides the
appropriate service. That obstructs development on new cloud plugin features!
Our internal teams will need a "dev override" capability, like what we offer
provider authors.
However, unlike with providers, we don't have to integrate this into a
heterogeneous mix of sources for mirroring and caching a wide range of binaries.
There's only one cloud plugin, HashiCorp controls it, and end users should never
need to override the location of the binary for non-development reasons.
Thus, we have the luxury of being quite a bit stupider in how we handle the
override signal. Instead of adding it to the CLI config file schema, we'll just
use a single environment variable whose value is the path to an alternate
binary.
Enter: `TF_CLOUD_PLUGIN_DEV_OVERRIDE`.
Adds a client that encapsulates the process of downloading a cloudplugin manifest from a Terraform Cloud, downloads the appropriate binary to the specified location, and validates that it was distributed by HashiCorp
