Bump Terraform provider to v1.113.0

[simonfaltum]

Why

Keep the CLI's Terraform schema in sync with the latest provider release (v1.113.0).

Changes

Bumps the provider version from 1.111.0 to 1.113.0 and regenerates the Go schema types using go run . in bundle/internal/tf/codegen.

New data sources and resources added:

• environments_default_workspace_base_environment
• environments_workspace_base_environment(s)
• postgres_catalog
• postgres_role(s)
• postgres_synced_table

Test plan

• make checks passes
• Existing unit/acceptance tests pass in CI

[pietern]

Does this match the # of command invocations?

Just to gut check that we're not doing 1 of these per TF request.

[simonfaltum]

Yes, it's per terraform invocation, not per API request. The provider calls /.well-known/databricks-config during initialization, so it happens roughly twice per terraform operation (plan, apply). Deploy runs plan+apply so you see ~4 provider calls, destroy similarly gets ~6. The single calls with cli/... user-agent are from the CLI SDK's own config resolution. I think there might be an effort looking into adding caching for this, but we'd have to ask @tanmay-db

[tanmay-db]

The current TF Release (v1.113.0) doesn't directly rely on this end point. This is called during Host metadata resolution in Go SDK and that is bumped in TF so I am guessing this is why this is needed here (not sure)? In very near future we plan to use this in TF

The plan is to add this in HostType() in Go SDK so

• Go SDK would call this endpoint store it in the config
• TF will check if this value is there in config

[pietern]

Was the previous one broken?

[simonfaltum]

We have added the .well-known/databricks-config as validation in terraform now, so it must match the expectation there

[tanmay-db]

@simonfaltum what was the failure on the previous workspaceID?

[simonfaltum]

The provider gets its workspace ID from X-Databricks-Org-Id header (900800700600), but /.well-known/databricks-config was returning 470123456789500. The mismatch caused all app tests to fail with "workspace_id mismatch: provider is configured for workspace 900800700600 but got 470123456789500 in provider_config".

[tanmay-db]

For context on why might have happened, we have recently launched support for default workspace id in apps: databricks/terraform-provider-databricks#5542. The call terraform is making for validation is scim/me and not .well-known.

The scim/me returns this workspace id and hence the conflict

	server.Handle("GET", "/api/2.0/preview/scim/v2/Me", func(req Request) any {
		return Response{
			Headers: map[string][]string{"X-Databricks-Org-Id": {"900800700600"}},
			Body:    req.Workspace.CurrentUser(),
		}
	})

cc: @simonfaltum @pietern @Divyansh-db

[pietern]

Not relevant for this case, I guess?

[simonfaltum]

The TF provider v1.113.0 makes extra /.well-known/databricks-config calls that the direct engine doesn't. Since both variants share out.requests.txt, the terraform variant now produces more requests than direct, causing a divergence. Disabling recording for this test sidesteps it since the test only cares about the plan output anyway.