volumes: make Terraform import work

[okrause]

This PR is a possible solution for volume import (see issue #33 ).

It implements approach number 1. It is the most simply solution and should work well, but will fail for the very unlikely corner case that more than one volume hold a volume with the requested volume UUID.

A proper importer which can also handle cases where multiple volumes with the same ID are found would be the cleaner solution.

This is how to use it:

1. Create an empty volume resource (volume.tf), e.g.:

resource "netapp-gcp_volume" "myvolume" {
}

2. Lookup the volumeID of the volume you want to import in the UI, e.g 6462b343-262c-e785-dc6c-ca5fcfc7e185.
3. Run the import
   terraform import netapp-gcp_volume.myvolume 6462b343-262c-e785-dc6c-ca5fcfc7e185
4. If it worked fine, TF will have imported the state of the volume into the terraform.tfstate file. Use
   terraform show -no-color > volume.tf to create the resource definition (overwriting the prior empty definition).
5. Delete the id line in volume.tf
6. Run terraform plan. If everything went fine, it should run without proposing changes.
7. Voila, you now have the definition in volume.tf and can start managing your volume with TF.

Happy to discuss.

[okrause]

Observation for shared-vpcs:
Importing and subsequent management of volumes with above method works fine.
Recreating the volume fails, since the TF files (generated via terraform show) are missing the shared_vpc_project_number attribute. It needs to be added manually to the TF file.

[okrause]

@lonico thank you for the input above.
Thinking about the ways to resolve multiple volumes with the same ID made me think about the actual problem again.

Our actual problem it, that ID is not guaranteed to be unique over all regions. The import command required a unique ID. So how would a unique ID look like? It is actually an (ID, region) tuple. Maybe we should simply require the user to specify both, e.g by requiring an ID in "CVSID:region_name" format. We could parse the components and don't need to guess the users intention.
Drawback is, that we cannot simply use the ID provided by the UI, might break user expectations and therefore need to document it well.

[lonico]

@okrause I like your idea about "CVSID:region_name". And we could support both format, if we assume that ":" cannot show in CSVID or region_name.
If we receive "CVSID", we try to find the region, but error out if multiple IDs are found. In the error message, we can ask for "CVSID:region_name" to resolve the ambiguity.
If we receive "CVSID:region_name" then we know where to look for.

[okrause]

@lonico Great proposal, like it a lot. It maintains user convenience and terraform import usage consistency, while proving a solution for this super rare corner case. Will update the PR over x-mas. Have a wonderful holiday.

[okrause]

Hohohoho, here are coming the x-mas eve changes to terraform import.

A user can continue to import using the standard way (ID = <volumeID>), e.g.
terraform import netapp-gcp_volume.myvolume 1bc88bc6-cc7d-5fe3-3737-8e635fe2f996.
If only one volume with this ID exists, the import will succeed. If multiple volumes with the ID exist, an error message will instruct the user to use the alternative format ID = <volumeID>:<region>, e.g.
terraform import netapp-gcp_volume.myvolume 1bc88bc6-cc7d-5fe3-3737-8e635fe2f996:us-central1

I also did some refactoring to reduce redundant code.

Feedback welcome