Apply some new go collection features

[dsa0x]

Applies some new collection features, specificially copying of maps and slices.

Fixes #

Target Release

1.12.x

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[jbardin]

these should all be maps.Clone when we're allocating the empty map just above

[dsa0x]

I did make some of them maps.Clone, but there was a single situation where that led to test failures because maps.Clone returns a nil object when the object-to-be-cloned is nil, but the test expected a zero-length map. That was what made me go all defensive and use Copy instead of Clone.

Perhaps it is sufficient to rely on tests and use maps.Clone anywhere possible? I got nervous about breaking things due to those changes.

[jbardin]

Oh, that's a good point! Some of these were probably counting on never returning a nil map. Anything that feeds into cty.ObjectVal is an obvious candidate, which would be map[string]cty.Value, though I only see one of those in this diff. Maybe if you can easily prove the code is fine passing through a nil map you could use Clone, and leave a comment why it's Copy on any you're unsure about? I would just want at least a comment bc someone may eventually come through and make the same change again later.

[dsa0x]

I added comments to the sections, where the map is returned, and thus may be used beyond the current scope.

For the ones where the map is immediately written to in the current scope, I find it redundant to add the comment, and expecting that one would ensure to allocate a map before attempting to write to it.

[dsa0x]

I had to fix a merge conflict @jbardin

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