Encode tag key as a single path segment in tag-policy and tag-assignment APIs

[renaudhartert-db]

Note

Supersedes #1713 with identical commits, authored by @lizhenxiang-db. That PR was opened from a personal fork, and fork PRs do not receive GitHub Actions OIDC tokens, so the required tests checks fail at JFrog authentication before running anything and the PR can never enter the merge queue. This PR carries the same branch pushed to origin so CI can run.

Summary

Percent-encode the governed tag key when it travels as a URL path parameter across the tag-policy and entity-tag-assignment APIs, so keys containing / route to the correct endpoint.

Why

Governed tag keys may be hierarchical and contain / (e.g. a/b). The generated clients interpolate the key straight into the request path (e.g. fmt.Sprintf("/api/2.1/tag-policies/%v", request.TagKey)), so a raw / is treated as a path separator and the request resolves to no matching endpoint (404 / ENDPOINT_NOT_FOUND). Get, Delete, and Update are affected.

A concrete consequence: the Terraform provider cannot refresh a databricks_tag_policy whose key contains /: every plan reads it as missing and tries to recreate it, which then fails because the policy already exists.

Create does not have this problem: it sends the key in the JSON request body, where / is valid and must be stored verbatim.

What changed

Interface changes

None. Method signatures are unchanged; only the encoding of the existing request path differs.

Behavioral changes

The tag-key path parameter is now url.PathEscaped (/ becomes %2F) before the request is sent, in:

• tags.TagPoliciesAPI: GetTagPolicy, DeleteTagPolicy, UpdateTagPolicy
• tags.WorkspaceEntityTagAssignmentsAPI: GetTagAssignment, DeleteTagAssignment, UpdateTagAssignment
• catalog.EntityTagAssignmentsAPI: Get, Delete, Update

The server decodes the key back to its original value, so behavior is unchanged for keys without special characters and fixed for keys that contain them. Only the tag-key parameter is encoded; entity_type / entity_id / entity_name are left untouched. The Create methods are intentionally not overridden (they send the key in the body).

Internal changes

• service/tags/ext_impl.go: hand-written overrides for TagPoliciesAPI and WorkspaceEntityTagAssignmentsAPI.
• service/catalog/ext_entity_tag_assignments.go: hand-written overrides for EntityTagAssignmentsAPI.
• NEXT_CHANGELOG.md: Bug Fixes entry.

How is this tested?

qa.HTTPFixtures unit tests in service/tags/ext_impl_test.go and service/catalog/ext_entity_tag_assignments_test.go assert the request path is encoded (/ becomes %2F) for the tag-policy and both entity-tag-assignment APIs. The full make test suite (1439 tests) and make lint pass locally on this branch merged with latest main.

[renaudhartert-db]

Hey @lizhenxiang-db, this is your #1713 with identical commits, pushed to an origin branch so CI gets OIDC tokens (fork PRs do not, which is why the tests jobs were failing at JFrog auth). I approved the original but GitHub will not let me approve a PR I opened. Can I have a quick stamp?

[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/sdk-go

Inputs:

• PR number: 1716
• Commit SHA: 5c671839edda7a45c7b0c1087eeadce1931f20e6

Checks will be approved automatically on success.