Prevent FAILED peerings/attachments from failing deletes

[jjti]

🛠️ Description

See: #393

I also bumped the AWS provider because anything < v4.0.0 fails out on ARM chips

🚢 Release Note

Release note for CHANGELOG:

* data_source_aws_transit_gateway_attachment
* data_source_aws_network_peering
* data_source_azure_peering_connection

🏗️ Acceptance tests

• Are there any feature flags that are required to use this functionality?
• Have you added an acceptance test for the functionality being added?
• Have you run the acceptance tests on this branch?

Output from acceptance testing:

--- PASS: TestAccAwsPeering (707.25s)
PASS
ok      github.com/hashicorp/terraform-provider-hcp/internal/provider   708.022s

[jjti]

closes #393

[chapmanc]

I think I am good with the logic but I am curious how you tested this? Did you create a failed peering on purpose and try to resolve it?

[bcmdarroch]

Thanks for the fix! If possible I'd like to encapsulate these failed state checks inside the peering helpers, rather than repeated over the data source functions.

[bcmdarroch]

Could we move this failed/delete check into the WaitFor*State helpers? We can check the state in the result here:

terraform-provider-hcp/internal/clients/peering.go

Line 77 in 974eaf2

result, err := stateChangeConfig.WaitForStateContext(ctx)

[jjti]

I'm a bit torn on DRY'ing this into the Waiters because of the shenanigans I'm trying to do here where:

• if it's a terminal state (FAILED/DELETING) at the start of the Read, throw a Warning
• if it's a terminal state after trying to wait in the Read, throw an Error

Also this is a specific (hack?) for the Peering data resources that I wouldn't want to add to WaitForPeeringToBeAccepted for example because we always want it to throw an Error there:

terraform-provider-hcp/internal/provider/resource_hvn_peering_connection.go

Line 156 in 441597c

peering, err = clients.WaitForPeeringToBeAccepted(ctx, client, peering.ID, hvn1Link.ID, loc, d.Timeout(schema.TimeoutCreate))

I'm not opposed necessarily, but because of two reasons above I left it within the data_resource_* Reads

[bcmdarroch]

Hmm I see, that does make sense. In the interest of getting this in, we can leave it like this for now, and revisit whenever we add another peering resource. Maybe leave a comment with that context?