[WIP] Allow update instead for recreate for aws_security_group_rule.

[tmccombs]

With this change, changes it cidr_blocks and ipv6_cidr_blocks will only
remove/add the cidr ranges that were removed/added in config, rather
than destroying the entire resource and recreating it.

It also changes the type of those attributes to sets to make the diffs
more readable.

Currently, aws_security_group_rule is destroyed and recreated whenever there is a change to cidr_blocks. Which is unacceptable, since adding a single cidr block to the resource could result in a service interruption.

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

Relates #10097

This is also related to #4726 which does something similar for the aws_security_group resource.

Release note for CHANGELOG:

- `cidr_blocks` and `ipv6_cidr_blocks` in `aws_security_group_rule` are now sets instead of lists, which provides better diffs when the list of cidr blocks is changed.
- `aws_security_group_rule` will now only remove and add the minimal number of IP ranges when `cidr_blocks` or `ipv6_cidr_blocks` are changed. This should prevent temporarily removing access for a security group while updating.

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'

TODO

[tmccombs]

I have not tested this at all yet. I'm also not entirely sure what tests if any I should add.

[zhelding]

Pull request #21306 has significantly refactored the AWS Provider codebase. As a result, most PRs opened prior to the refactor now have merge conflicts that must be resolved before proceeding.

Specifically, PR #21306 relocated the code for all AWS resources and data sources from a single aws directory to a large number of separate directories in internal/service, each corresponding to a particular AWS service. This separation of code has also allowed for us to simplify the names of underlying functions -- while still avoiding namespace collisions.

We recognize that many pull requests have been open for some time without yet being addressed by our maintainers. Therefore, we want to make it clear that resolving these conflicts in no way affects the prioritization of a particular pull request. Once a pull request has been prioritized for review, the necessary changes will be made by a maintainer -- either directly or in collaboration with the pull request author.

For a more complete description of this refactor, including examples of how old filepaths and function names correspond to their new counterparts: please refer to issue #20000.

For a quick guide on how to amend your pull request to resolve the merge conflicts resulting from this refactor and bring it in line with our new code patterns: please refer to our Service Package Refactor Pull Request Guide.

[ewbankkit]

@tmccombs Thanks for the contribution 🎉 👏.
I'm going to close this pending a simpler implementation of Security Group rules as required for #20104.

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