refactor: finish moving device resource off of packngo

[ctreatma]

We previously migrated the Equinix Metal device data source and the read pathways for the resource from packngo to metal-go (and then to equinix-sdk-go). This finishes the migration of the device resource by replacing packngo with equinix-sdk-go in the create, update, and delete pathways for that resource.

[codecov-commenter]

Codecov Report

Attention: 757 lines in your changes are missing coverage. Please review.

Comparison is base (26b2f3d) 60.11% compared to head (cebf38a) 59.06%.
Report is 129 commits behind head on main.

❗ Current head cebf38a differs from pull request most recent head 5bab641. Consider uploading reports for the commit 5bab641 to get more accurate results

Files	Patch %	Lines
internal/errors/errors.go	7.05%	145 Missing ⚠️
equinix/fabric_mapping_helper.go	0.00%	69 Missing ⚠️
equinix/resource_metal_device.go	73.91%	44 Missing and 16 partials ⚠️
equinix/resource_fabric_connection.go	0.00%	53 Missing ⚠️
equinix/resource_fabric_cloud_router.go	0.00%	43 Missing ⚠️
equinix/resource_network_device.go	2.50%	39 Missing ⚠️
equinix/resource_fabric_service_profile.go	0.00%	26 Missing ⚠️
internal/resources/metal/metal_ssh_key/resource.go	73.62%	19 Missing and 5 partials ⚠️
equinix/resource_fabric_routing_protocol.go	0.00%	23 Missing ⚠️
equinix/resource_metal_virtual_circuit.go	50.00%	13 Missing and 2 partials ⚠️
... and 43 more

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #501      +/-   ##
==========================================
- Coverage   60.11%   59.06%   -1.06%     
==========================================
  Files          99       96       -3     
  Lines       20045    19855     -190     
==========================================
- Hits        12051    11727     -324     
- Misses       7691     7832     +141     
+ Partials      303      296       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[displague]

lgtm

[ctreatma]

So...after digging into what it means for a device to be locked and confirming that we don't have to use a separate update request to change the lock status, it turns out that locked is a computed attribute for a metal_device resource, so it's not actually possible to hit this code path anyway.

So: do we want to stick with the existing behavior that locked can't be changed or do we want to support locking/unlocking devices in terraform?

For reference, this is the information we got about what locking does:

It seems that locking a device prevents you from:

• Delete/deprovision the device
• Reinstall the device
• Prevents an instance with a termination time set to be reclaimed, even if the termination time was reached (for spot instances, we will reclaim it anyway)
• Perform a Firmware update on the device (this feature is not GA yet)

[cprivitere]

I feel like it's a core state for our devices to support and so terraform should be able to do it.

[displague]

The list of lock affecting features is helpful context. Without that we may expect behaviors that are not present today: https://feedback.equinixdigital.com/instances/p/expand-lock-feature-for-metal-servers.

It's worth considering the ways Terraform and a Portal user would interact through EM API device locking (not to be confused with Terraform state locking).

If Terraform takes an "optional" (default=false) behavior, rather than computed, then plan/apply from Terraform would inform users that an externally applied lock is going to be reset upon change.

When Terraform config requests lock, then any API changes that are incompatible with lock would fail until the Terraform config is modified to lock=false (or the lock line is removed).

I'm not seeing any problems in taking this approach.

[ctreatma]

OK, sounds like we're all agreed; I'm going to update the resource so that locked can be set and update the docs accordingly.

[ctreatma]

I enabled locking/unlocking a device resource; this PR has been updated but here's a direct link to the commit that has those changes: 836f1f0

I opted to make locked optional and computed, rather than optional with a default. IMO changing it from computed to default has a bigger impact on existing users, because if we switch to a default of false then any terraform user who currently has a locked device is at risk for accidentally unlocking the device as a result of a non-major-version provider upgrade.

[displague]

The only E2E failure that doesn't look like flake, but also looks to be unrelated:

=== NAME  TestAccMetalSpotMarketRequestCreate_WithTimeout
    resource_metal_spot_market_request_acc_test.go:245: Step 1/1, expected an error with pattern, no match on: Error running apply: exit status 1
        
        Error: POST https://api.equinix.com/metal/v1/projects/0667bb71-9428-4919-8c1d-58fc0fb95613/spot-market-requests?include=devices%2Cproject%2Cplan: 422 2.21 exceeds the maximum bid price of 2.20 
        
          with equinix_metal_spot_market_request.request,
          on terraform_plugin_test.tf line 122, in resource "equinix_metal_spot_market_request" "request":
         122: resource "equinix_metal_spot_market_request" "request" {