Add support for updates to resource type(s)

[owenfarrell]

Signed-off-by: Owen Farrell owen.farrell@gmail.com

Fixes #140

PR Checklist

---

• [x] I have read the CONTRIBUTING.MD instructions
• [ ] I have changed the resourceDefinition.json
• [ ] I have generated the resource model (there's a models_generated.go file in my PR)
• [ ] I have updated the README.md#resource-status
• [x] I have checked to ensure there aren't other open Pull Requests for the same update/change?

Description

Does this introduce a breaking change

• [ ] YES
• [x] NO

While this doesn't inherently introduce a backwards-breaking change, I don't see a way to support auto-upgrades of the current version of the provider to support this change. Anyone who attempts to auto-upgrade will incur the existing behavior (a forced deletion/recreation of downstream resources) one more time. Any suggestions on how to mitigate this issue would be appreciated.

Testing

In addition to local unit testing, I've exercised these updates via a local provider override and it seems to meet the need.

$ make build
go generate

2022/10/13 15:40:19 File generated
go fmt ./...
azurecaf/models_generated.go
azurecaf/provider_test.go
go build -o ./terraform-provider-azurecaf
go test ./...
?       github.com/aztfmod/terraform-provider-azurecaf  [no test files]
ok      github.com/aztfmod/terraform-provider-azurecaf/azurecaf 22.411s
?       github.com/aztfmod/terraform-provider-azurecaf/completness      [no test files]

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[owenfarrell]

In stewing on this a bit more, I took a crack at what an "auto-upgrade" approach looks like as part of #203. The idea is that it reverse engineers the random suffix that was generated based on existing result(s) using a guess-and-check approach.

[arnaudlh]

Closing as superseded by #203