fix: convert User Policies to unordered set to prevent policy thrashing

[bushong1]

Description of the change

I’ve been having some trouble with the Spacelift Terraform provider when managing user access policies. Every time I add a new policy, Terraform tries to delete and recreate some of the existing ones—even though they haven’t changed at all. It’s like it’s getting confused about what’s actually new and what’s already there.

I think the problem is with how the policy field is set up in the spacelift_user resource. Right now, it’s defined as a TypeList, which is ordered. So when I insert a new policy somewhere other than the end of the list, it shifts the order, and Terraform thinks the policies have changed.

To fix this, I think we should change policy from a TypeList to a TypeSet. Sets are unordered, so Terraform won’t care about the order of the policies anymore. Also, by adding a custom hash function that combines space_id and role, we can uniquely identify each policy.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (non-breaking change that adds documentation)

Related issues

Relates to #549, potentially sets the state to support a policy attachment feature in the future

Checklists

Development

• Lint rules pass locally
• The code changed/added as part of this pull request has been covered with tests
• All tests related to the changed code pass in development
• Examples for new resources and data sources have been added
• Default values have been documented in the description (e.g., "Dummy: (Boolean) Blah blah. Defaults to false.)
• If the action fails that checks the documentation: Run go generate to make sure the docs are up to date

Code review

• This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• Pull Request is no longer marked as "draft"
• Reviewers have been assigned
• Changes have been reviewed by at least one other engineer

[peterdeme]

it looks good to me. my only concern is that this type change (List -> Set) will show up as a change in the plan for all existing customers. could be worth to mention in the release changelog.

[bushong1]

@peterdeme is the changelog something I need to do? Also is there a way to get the "Test the code" job triggered to conclude the PR requirements?

[peterdeme]

@bushong1

• Changelog: that's autogenerated on release. We (Spacelift) can update it afterwards though.
• CI/CD: the reason it won't kick off is because it contains secrets and the PR was opened by an external contributor. GitHub doesn't allow that for security reasons. We'll (Spacelift) need to open another PR copying your commit. We can do that, I'd just like to wait for @adamconnelly's review.

[bushong1]

@peterdeme ahh ok. Well I just rebased to a single signed commit to satisfy that requirement, but I guess that won't matter if you're opening a new PR.

[adamconnelly]

Looks great to me as well @peterdeme.

@bushong1 thanks a lot for this contribution!

@peterdeme I agree with the concern about upgrading. Let's check what happens if you have a state using the current provider version, then switch to this version and apply before merging.

[peterdeme]

@bushong1 thanks for the contribution! 🙏

I ported your change into #587 so that the tests can run.