Avoid cloud ssh public key name collision

[twiest]

• [x] Avoid cloud ssh public key name collision between multiple clusters by defaulting the cloud ssh public key name to clusterid
• [x] Add deprovisioning of the cloud ssh keypair when the keypair name matches clusterid
• [x] Add unit test for specifying a keypair name
• [x] Add unit test for generating a keypair name
• [x] Test that clusters are created using autogenerated name
• [x] Test that nothing is using "libra" as the cloud ssh public key name

[twiest]

This is a WIP because I'd like the team to weigh in on the decisions made.

Specific questions:

• Are we ok with removing the ability for an end user to specify the cloud ssh public key name? I think this is consistent with the other cloud infra pieces that we manage, just want to make sure the team is ok with it as well.

• Should the cloud ssh public key name contain a postfix like "-provision" since it is only used during host provisioning? Ssh key management after that is handled by a daemon set in the cluster.

• Is there a better location for the generating the cloud ssh public key name? This PR is currently doing it here. I searched around and this seemed like the best location to me, but I'm open to moving it if there is a better location.

[dgoodwin]

Regarding the key only being used during provisioning, it remains on the systems though right? I.e. this may be a common way admins get access in the event of a serious failure. I'm not sure we've got that daemonset fully hooked up yet either, and I'm not sure where it's headed for 4.0 anymore.

For a typical account I would expect they plan to upload one master key and want to use it for all their clusters in the account. As such I think we should keep the door open for specifying it as part of your cluster deployment spec, and then a CO deployment or the tooling in front of it can do either as desired. If you're spinning up dozens of clusters in a new UI, it would be nice not to force you to paste in the same ssh key every time.

Clobbering keys could still be an issue for our development playbooks though, and we could tackle the problem there if desired. I'm not terribly worried about clobbering libra as that's really all we need to use, but if we're running into issues I could see us handling it in the playbooks by assuming to create an ssh key in AWS with the cluster name, each time we run create-cluster. Worth noting however that nothing can clean those up, as it's not a part of deprovision we can assume to do, and there is no deprovision playbook. We'd have to write something to scan and delete.

[twiest]

@dgoodwin I believe I've addressed your feedback given in this PR and in the meeting today. Would you please mind reviewing again?

The only thing not addressed yet is deprovision, which @joelddiaz thinks there's a flag to deprovision the cloud public ssh key in the deprovision playbook.

If the provisioning in this PR looks good to you, then I'd like to discuss the deprovisioning tomorrow sometime.

[twiest]

@dgoodwin @csrwng I added uninstalling the key and unit tests to verify the functionality.

I think this is ready to merge. I've removed the WIP tag from the title.

Can I please get a re-review from either one of you?

[dgoodwin]

/lgtm