Defer/lazy loading of provider configuration

[bdalpe]

Preflight Checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions
• [ ] I have joined the ZITADEL chat

Describe your problem

When running terraform commands with the Zitadel provider, the provider attempts to immediately load the configuration. This is an issue when attempting to deploy the Zitadel Helm chart (as a helm_resource) and then immediately create resources using the Zitadel provider.

For example, here is an abstract of the Terraform I'm using to provision Zitadel on a k8s cluster:

resource "helm_release" "zitadel" {
  name = "zitadel"
  namespace = "zitadel"

  ...

  values = [<<-YAML
    zitadel:
      ConfigMapConfig:
        FirstInstance:
          Org:
            Machine:
              Machine:
                Username: ${var.zitadel_admin_username}
                Name: ${var.zitadel_admin_username}
              MachineKey:
                ExpirationDate: "2030-01-01T00:00:00Z"
    ...
    YAML
    ]
}

data "kubernetes_secret" "zitadel_admin_key" {
  metadata {
    name = var.zitadel_admin_username
    namespace = helm_release.zitadel.namespace
  }

  depends_on = [helm_release.zitadel]
}

provider "zitadel" {
  domain = var.zitadel_domain
  jwt_profile_json = data.kubernetes_secret.zitadel_admin_key.data["${var.zitadel_admin_username}.json"]  # Fails here!
}

data "zitadel_orgs" "orgs" {}

...

But this fails planning and apply because the Zitadel provider attempts to load the jwt_profile_json string which is blank because the data resource isn't populated yet. The provider also errors when the helm_release is tainted or needs to be updated.

╷
│ Error: either 'jwt_profile_file' or 'jwt_profile_json' is required
│ 
│   with ...,
│   on ..., in provider "zitadel":
│   provider "zitadel" {
│ 
╵

I can work around this issue by running a "progressive apply":

terraform apply -target=data.kubernetes_secret.zitadel_admin_key
terraform apply
# success!

But this is not ideal for me. I would like to see the provider only load the configuration when it needs to actively do something with a resource or data block. I base this request on the functionality of the Terraform kubernetes, helm, and kubectl providers because they all defer the loading of the kubeconfig until making API calls. It would be awesome if the Zitadel provider could support this!

Describe your ideal solution

As a system administrator, I would like the Zitadel provider to wait to attempt to load the machine user's key file until a dependent resource is available.

Version

1.1.1

Additional Context

No response