Handle marks on ignore_changes values

[jbardin]

Up until now marks were not considered by ignore_changes, that however
means changes to sensitivity within a configuration cannot be ignored, even
though they are planned as changes.

Rather than separating the marks and tracking their paths, we can easily
update the processIgnoreChanges routine to handle the marked values
directly. Moving the processIgnoreChanges call also cleans up some of
the variable naming, making it more consistent through the body of the
function.

Fixes #29173 in conjunction with hashicorp/hcl#478

[apparentlymart]

I had to mull this one a bit because the idea of ignoring changes to sensitivity had me a little worried about the case of ignoring a change from nonsensitive to sensitive.

However, after some thought experiments I think this is safe and sound because the meaning of ignore_changes is to keep what's in the prior state regardless of what the configuration said, and dynamic sensitivity (as opposed to the static sensitivity from the provider schema) always originates in the configuration, and so there shouldn't be any case where the remote system can end up putting a newly-sensitive value into an argument that was originally assigned as non-sensitive... that would be possible only if the provider had some way to signal dynamically that a particular value is sensitive, but even if we do add that later the provider would hopefully indicate that during ReadResource rather than in PlanResourceChange and so the change in sensitivity would come through as a funny sort of drift rather than as part of the planned change.

The one exception to this rule I can think of is terraform_remote_state, which gets to cheat a bit by virtue of being built in to Terraform and thus not having to traverse the provider wire protocol. It can and does return dynamically-sensitive values, but it's a data source and so not subject to ignore_changes anyway.

If the above all seems to add up to you too (and doesn't spark any ideas for new potential problems I didn't consider), then this LGTM!

[jbardin]

The situation you are describing is basically what led me to fixing this in the first place. A combination of the impure function behavior with a bug in HCL was causing the value to change it's sensitivity during planning, resulting in a planned change that could not be ignored. While it's unlikely most users would ever encounter this under normal use, it could also be triggered by manual changes in the config (shown in the existing test I had to fix), and generally seems more "correct" in the behavior of ignoring any changes caused by the configuration to the existing resource state.

[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.