Fix sensitive values being replaced with '(sensitive value)' in Helm deployments

[abatilo]

When using set_sensitive in the helm provider, the actual values deployed to
Kubernetes were incorrectly replaced with the string '(sensitive value)' instead
of the real sensitive value.

Root cause:
The logValues() function was using maps.Clone() which only creates a shallow
copy. Since Helm values are nested maps (e.g., {'configmap': {'foo': 'test'}}),
the inner maps were shared between the original and clone. When cloakSetValues()
modified the 'cloned' map to mask sensitive values for logging, it was actually
modifying the original map that was then passed to Helm for deployment.

Fix:

• Implemented deepCloneMap() function that recursively clones nested maps
• Updated logValues() to use deepCloneMap instead of maps.Clone
• Updated setReleaseAttributes() to use deepCloneMap for consistency
• Removed unused 'maps' import

This ensures sensitive values are properly masked in logs and Terraform state
display while the actual values are correctly deployed to Kubernetes.

Fixes the issue where ConfigMaps would contain '(sensitive value)' instead of
the actual sensitive data when using set_sensitive blocks.

[abatilo]

@jrhouston would you mind taking a look?

[abatilo]

This PR fixes the (sensitive value) bug described here:
#1637 (comment)

[jrhouston]

Thanks for jumping in to fix this @abatilo. I've pushed a reproducer test for this to your branch, which passes with your change.

It looks like the code that got missed in the migration from SDKv2 is this janky JSON Unmarshal/Marshal step which I guess is a cheat way to do a deep copy.

terraform-provider-helm/helm/resource_release.go

Lines 1425 to 1431 in afc64ed

	// copy array to avoid change values by the cloak function.
	asJSON, _ := json.Marshal(values)
	var c map[string]interface{}
	err := json.Unmarshal(asJSON, &c)
	if err != nil {
	return err
	}

[abatilo]

Of course @jrhouston , happy to try and contribute.

Sorry, can you help me understand what I should do next? I see some acceptance tests are failing. Should I be the one trying to fix those? Or are you taking over the branch, etc?

[jrhouston]

My apologies, that test was failing because I added a secret to the test chart for testing the sensitive values but forgot to update one of the tests which asserts the number of templates in the chart. I've fixed the test and pushed it, everything should turn green now.

I think this PR will be good to go, we will need a second approval from @jaylonmcshan19-x before I can hit merge.

[abatilo]

Amazing. Thank you so much.

[jgournet]

I know this does not help in any way, but:
Thank you very much for addressing this so fast !

[jaylonmcshan19-x]

Thanks for addressing this bug @abatilo @jrhouston :)