feat: add autokey plus migration

[romanini-ciandt]

The goal of this PR is to provide instructions for customers to migrate the Terraform Key Handle state from terraform-google-autokey to autokey submodule in this repo

[g-swap]

Reviewing the PR

[tdbhacks]

Nice!! Left two minor comments.

I assume this is hard / infeasible / not worth to test with an automated test, do you mind maybe sharing a sample step by step example log of this process?

[tdbhacks]

Is this needed because the import script will import the existing keyhandles into TF resources that include the random suffix in the name, but we need to ignore the diffs on apply?

Or is it unrelated and more of a general autokey module improvement, to address what we discussed offline re: users changing the keyhandle name and then running into issues when they try to change it back?

[romanini-ciandt]

A short answer would be:
It is to address issues on both (when imported or not), but the change was motivated to support the import process. It would impact 100% of the imports and just eventual use cases for not imported.

More context about why:
I added this lifecycle to avoid resource replaces when importing existing key handles. When we import, this submodule will try to append a random suffix and a replacement will be forced.

But also, as we discussed offline, this change would avoid errors even when the user is not importing.
Example: The key Handle for secret manager can not be recreated, just 1 instance per project is allowed by GCP. In this case, if the name is changed in tf, terraform will "destroy" (not actually destroy, but remove it from tf state) and the attempt to create a new resource will raise an error.

So, I chose this lifecycle approach, but I also see two others alternatives:

1. Add a boolean flag in input variables, so users can control if to append the random suffix into key Handles or not. But the con in this approach is that all the key handles would need to have the same behavior (imported or not), and also we wouldn't be preventing the secret manager issue I mentioned above.
2. Add a new key handle tf resource specifically for import process. The con in this approach is that, beyond the tf resource duplication, we would need to specify in .tfvars file different variables names for imported and non-imported key handles

Sorry for the length of the comment... but is it clear?
Let me know what you think, or if we should change the approach here :)

[tdbhacks]

Gotcha, thanks for confirming! This all makes sense to me and seems reasonable, I'll defer to the CFT team and see if they disagree :) Thank you!

[romanini-ciandt]

Nice!! Left two minor comments.

I assume this is hard / infeasible / not worth to test with an automated test, do you mind maybe sharing a sample step by step example log of this process?

@tdbhacks here is the step by step being executed:

• Getting the existing Autokey state from terraform-google-autokey module
  

• Creating the .tfvars file
  
  

• Importing the existing Autokey state from terraform-google-autokey module using autokey submodule
  
  
  

• terraform apply after the import
  
  Note that 6 resources were added. None of them were key handles because at this point they're already imported. These are the other terraform resources that autokey submodule have (service agent activation, assign permissions to sa, Autokey config, random, etc.)

• Cleaning your local environment
  

[tdbhacks]

Awesome, thanks Leo!!

[erlanderlo]

one minor comment to consider, so I'll leave it up to you to address.

[romanini-ciandt]

@apeabody could you PTAL?

[apeabody]

Approved by @tdbhacks & @erlanderlo