[Fix] support updating catalog name

[eric-carlsson]

Changes

Fixes #3818

This PR adds missing logic for handling the renaming of Catalogs.

Tests

• make test run locally
• relevant change in docs/ folder
• covered with integration tests in internal/acceptance
• using Go SDK
• using TF Plugin Framework

Have tested against live Databricks deployment and works as expected.

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/terraform

Inputs:

• PR number: 4579
• Commit SHA: afc7c3f88f97c3cb2a557bcd068f43b9f7da3921

Checks will be approved automatically on success.

[alexott]

The problem is not in the renaming itself (btw, you forgot to set id in the update method. The problem is with the downstream objects that need to be updated as well, and not all of them support renames - like, Vector Search indexes will be tainted and this will lead to their recreation.

To support renaming, UC catalogs (and schemas, etc.) must use some stable ID (like, UUID generated during the creation).

[eric-carlsson]

btw, you forgot to set id in the update method.

id was already set from the returned object, am I missing it somewhere else?

terraform-provider-databricks/catalog/resource_catalog.go

Lines 181 to 183 in afbaf07

	// We need to update the resource data because Name is updatable
	// So if we don't update the field then the requests would be made to old Name which doesn't exists.
	d.SetId(ci.Name)

The problem is with the downstream objects that need to be updated as well, and not all of them support renames - like, Vector Search indexes will be tainted and this will lead to their recreation.

I'm aware that renaming catalogs can have side-effects, but I think that's a concern for the user of the provider and not the provider itself. By not supporting this behavior, we are effectively forced to manually manipulate the state if we want to move catalogs, which is arguably even worse.

Most of the downstream objects already mark the catalog_name field with forceNew. Shouldn't this be sufficient to inform the user that renaming the catalog can be a destructive action? If the user is not ok with this, they can add removed and import blocks for the downstream objects to "manually" migrate their IDs. Regardless, it's left up to the user to decide.