Upjet generated providers shouldn't use Terraform Providers as Go Modules

[rickard-von-essen]

Currently some Upjet generated providers (provider-upjet-gcp, provider-upjet-aws), but goes against HashiCorps policy:

Do Not Import Providers as Go Modules

Terraform's providers are written as Go packages, and they mostly use Go modules as their dependency management solution. This makes it tempting to import the provider as a dependency of your Go code, and to call its exposed interface. This is explicitly an unsupported way to interact with providers and provider maintainers make no guarantees around backwards compatibility or the continued functioning of code that does this.

https://developer.hashicorp.com/terraform/plugin/best-practices/interacting-with-providers#do-not-import-providers-as-go-modules

[mergenci]

Thanks for opening this issue @rickard-von-essen 🙏 I don't agree that Upjet-based providers shouldn't import Terraform providers, just because Terraform recommends against doing so. In big Upjet providers, we do so by paying the cost of making Terraform provider upgrades backwards compatible. The problem, however, is that Upjet doesn't offer an in-between alternative between using Terraform CLI and importing the providers. Currently, making a provider no-fork (free from Terraform CLI) is a rocky road. Hopefully, we can offer an alternative to those who would like to keep the maintenance cost low.

[jonasz-lasut]

As per @mergenci comment - we ensure the backwards compatibility in major cloud providers on our own. I'll close this issue as this approach is heavily baked into upjet's architecture and we don't expect changing it in the nearest future (or at all)