fix: change streams to be a SetNestedAttribute

[perangel]

This commit modifies the connection resource's streams attribute to be a SetNestedAttribute instead of a List. This is so that we can properly compute plan's that treat re-ordering of elements (streams) as a noop (if no attributes of the stream have been changed).

Previously if you added a new stream to a connection resource in the middle of the list, or changed the order, the provider would compute that as a change that had to be applied.

Additionally, we use a customer SetPlanModifier that may be parameterized with a key which is used to uniquely identify the elements in the set.

NOTE: the current implementation of the plan modifier uniqueByKey assumes that the elements of the set are Objects. Since this is the only use case for this modifier, this seems reasonable for now.

Testing

If you would like to verify these changes yourself, and do not have access to our SpeakEasy account, you can checkout this branch and run the provider locally in debug mode.

go run main.go -debug

NOTE: This will output instructions for exporting a TF_REATTACH_PROVIDERS env var that you must set when invoking terraform so that it uses the local instance of the provider.

[perangel]

Since these files have been manually modified, we need to exclude them from generation.

[perangel]

I'm not entirely certain that we need to remove these plan modifiers, so I defer to someone with more background to correct me here if this is not the right approach

[szemek]

@perangel I compiled your changes and provider works fine 👌🏻
Out of curiosity, what edge cases your changes cover that are not included in my pull request #111 ?

[perangel]

@perangel I compiled your changes and provider works fine 👌🏻 Out of curiosity, what edge cases your changes cover that are not included in my pull request #111 ?

There are some SpeakEasy SDK/Provider generation configurations that need to be in place so that when the code gets generated it doesn't clobber the changes (see: .genignore). I'm also not entirely certain that the custom plan modifier is strictly necessary. I had been following some guidance from the speakeasy team and should hopefully get a review from them soon.

[ThomasRooney]

Tested and works well for me! I've run this through the set of tests with reordering streams that I tried when it was just a SetNestedAttribute and everything looks good; infrastructure gets to a stable state.

[ThomasRooney]

Note: for context on why this was necessary over-and-above just converting streams to a SetNestedAttribute, we ran into behaviour where terraform would always pick up a change under streams even after converting it to a Set. When UseStateForUnknown (the diff suppression plan modifier) was applied to try and mitigate this, we ran into hashicorp/terraform-plugin-framework#709; data misalignment of the streams (plan+state couldn't be combined and got jumbled up) after the Read() method in the RefreshState lifecycle step.

References:

• Classifying normalization vs. drift #70
• Unexpected Behavior With Plan Modifier (UseStateForUnknown) Prior State Under Lists and Sets #709
• resource/schema: Prevent UseStateForUnknown data misalignment by raising implementation error when under a list or set #711
• Consider MatchElementStateForUnknown() Plan Modifiers #717
• resource/schema: Implement MatchElementStateForUnknown plan modifier #718
• Allow provider maintainers to define identifying attributes which should always be shown in plan diffs terraform#30753