feat: add project API key resource

[rawkode]

This PR aims to add support for creating project level API Keys.

[displague]

If this field were not required, this resource could be metal_api_key with optional project scoping.

[displague]

FWIW, I recognize that we have both metal_project_ssh_key and metal_ssh_key.

I'm not sure that I see a reason for the distinction, then or now. project_ssh_keys came a few years after ssh_keys.
https://github.com/equinix/terraform-provider-metal/blob/main/metal/resource_metal_project_ssh_key.go

When I was first introduced to the API, I found some justification for this because some resources are created behind /projects/id/foo, while others are not. After a bit more exposure to the API, I find that resources (project or not) are all typically accessible behind /foo/id. Project scoped or not, these optionally scoped resources have the same response body, other than the project id field.

When a resource is project scoped, the API path contains the (optional) project_id rather than the POST body. If a listing endpoint is present in /projects/id/foo, it is offered as a convenience to /foo?project_id=id.

They are otherwise the same.

[t0mk]

@rawkode @displague I think we can do both metal_user_api_key and metal_project_api_key in a similar way as the ssh_keys.

Just make the project_id Optional: true. Create and Delete methods can be shared between metal_user_api_key and metal_project_api_key. You will need to have separate Read methods.

@displague I dived to the API key methods and created equinixmetal-archive/packngo#297

[rawkode]

For what it's worth, I did consider using a single resource for both and I do prefer that API, but unfortunately the backing API at EM doesn't provide a single read endpoint. I did consider working around that, but importing a resource wouldn't work and I thought that was more important. Perhaps we can work with engineering to clean up this API. 

[t0mk]

@rawkode you're right that the read endpoint for user API key is different. You could create a resource for the API key, reusing some of the project API key code. If you'd change the project_id to Optional: true, you could just add resource_metal_user_api_key.go as

func resourceMetalUserAPIKey() *schema.Resource {
	return &schema.Resource{
		Create: resourceMetalProjectAPIKeyCreate,
		Read:   resourceMetalUserAPIKeyRead,
		Delete: resourceMetalProjectAPIKeyDelete,
		Importer: &schema.ResourceImporter{
			State: schema.ImportStatePassthrough,
		},

		Schema: metalProjectAPIKey(),
	}
}

func resourceMetalUserAPIKeyRead(d *schema.ResourceData, meta interface{}) error {
	client := meta.(*packngo.Client)
	apiKey, err := client.APIKeys.UserGet(d.Id(), nil)
	if err != nil {
		err = friendlyError(err)
		if isNotFound(err) {
			log.Printf("[WARN] User APIKey (%s) not found, removing from state", d.Id())
			d.SetId("")
			return nil
		}
		return err
	}
	d.SetId(apiKey.ID)
	d.Set("description", apiKey.Description)
	d.Set("read_only", apiKey.ReadOnly)
	d.Set("created", apiKey.Created)
	d.Set("updated", apiKey.Updated)
	return nil
}

.. the user API key resource would actually be importable.

If you don't want to do it in this PR, it's OK we can add metal_user_api_key later. Thsis is good to go after you remove the Import and the Update method.

[t0mk]

@rawkode @displague I think we can do both metal_user_api_key and metal_project_api_key in a similar way as the ssh_keys.

Just make the project_id Optional: true. Create and Delete methods can be shared between metal_user_api_key and metal_project_api_key. You will need to have separate Read methods.

@displague I dived to the API key methods and created equinixmetal-archive/packngo#297

[t0mk]

terraform import only allows to use one parameter, usually it's resource UUID. In case of resources like this, which need 2 params - project ID and key ID, you can't really do import out-of the box like you did.

It can be solved by parsing both IDs from a single string "<project_id>:<key_id>" (https://www.terraform.io/docs/extend/resources/import.html#importer-state-function), and implementing custom Resource Importer, but I'm not sure if we need import of this resource right here right now. Maybe it's better if you just remove the importer (for the project_api_key).

[t0mk]

Update of API key is impossible. Remove the Update method.

[t0mk]

@rawkode I refactored your code a bit and added metal_user_api_key and tests for both resources. I will later write docs and ask you and @displague to review.

[t0mk]

@displague this is ready for review