lang/funcs: Conversion functions can handle sensitive values

[apparentlymart]

In order to avoid updating every one of our existing functions with explicit support for sensitive values, there's a default rule in the
functions system which makes the result of a function sensitive if any of its arguments contain sensitive values.

We were applying that default to the various type conversion functions, like tomap and tolist, which meant that converting a complex-typed value with a sensitive value anywhere inside it would result in a wholly-sensitive result.

That's unnecessarily conservative because the cty conversion layer (which these functions are wrapping) already knows how to handle sensitivity in a more precise way. Therefore we can opt in to handling marked values (which Terraform uses for sensitivity) here and the only special thing we need to do is handle errors related to sensitive values differently, so we won't print their values out literally in case of an error (and so that the attempt to print them out literally won't panic trying to extract the marked values).

---

The more-conservative-than-needed sensitivity here was mainly just a cosmetic annoyance, but it has a more practical implication when using tomap or toset to prepare a partially-sensitive collection for use in for_each:

locals {
  sensitive_parts = tomap({
    boop = "hello"
    beep = sensitive("goodbye")
  })
}

resource "null_resource" "example" {
  for_each = local.sensitive_parts
}

Without this PR, the for_each in null_resource.example is invalid because the whole map is marked as sensitive. After this PR it works because the map itself is known and only local.sensitive_parts["beep"] returns an unknown value.

[codecov]

Codecov Report

Merging #28446 (ea7ae72) into main (85adad0) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted Files	Coverage Δ
lang/funcs/conversion.go	90.47% <100.00%> (+0.73%)	⬆️
terraform/node_resource_plan.go	96.11% <0.00%> (-1.95%)	⬇️
backend/remote/backend_common.go	50.51% <0.00%> (+0.69%)	⬆️
internal/providercache/dir.go	73.46% <0.00%> (+6.12%)	⬆️

[apparentlymart]

There are more functions like this which would benefit from special treatment of sensitive values in order to produce a more precise result, and so I expect PRs for those will follow soon too. There are opportunities for this for any function that works generically with the elements of a collection, without inspecting those element values directly: if an element gets copied verbatim into the result then the sensitivity of that element should come with it, but we should avoid having the whole collection become sensitive in that case whenever it's reasonable to do that.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.