* Update protoc version in downloader script
* go get google.golang.org/grpc/cmd/protoc-gen-go-grpc v1.5.1
This matched terraform-plugin-go
* make protobuf
* Run `make protobuf`
* Update generator to handle generic types from google.golang.org/grpc
Looks like this was added in v1.69.3 in https://github.com/grpc/grpc-go/pull/7057 ?
* Run `make generate`
* Fix "cannot infer Res" compile error - more usage of generics
* More fixing compile errors due to switching to use of a generic
* Make putting `google.golang.org/grpc` import into generated files conditional
* Run `make generate`
* Update more places where generics now need to be used
* Update generator to handle any types from google.golang.org/grpc in same switch case.
- 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.