Tpm support

[ccravens]

Adding AWS NitroTPM support to AMI. More information can be found here:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enable-nitrotpm-support-on-ami.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enable-nitrotpm-prerequisites.html

There is a flag that is not currently supported by the Packer AMI Builder: --tpm-support v2.0

This update is meant to resolve that. I am not a packer plugin developer, but added what I believe to be the basic necessary code and tried my best to maintain the compatibility of the code based on the other options that are currently there. I want to see this feature as soon as possible so if there are updates that need to be made please let me know.

Both go build and make dev seem to work.

Testing results in the following output:

$ make test
go: downloading github.com/stretchr/testify v1.7.0
go: downloading gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b
?   	github.com/hashicorp/packer-plugin-amazon	[no test files]
ok  	github.com/hashicorp/packer-plugin-amazon/builder/chroot	1.781s
ok  	github.com/hashicorp/packer-plugin-amazon/builder/common	0.520s
?   	github.com/hashicorp/packer-plugin-amazon/builder/common/awserrors	[no test files]
?   	github.com/hashicorp/packer-plugin-amazon/builder/common/ssm	[no test files]
ok  	github.com/hashicorp/packer-plugin-amazon/builder/ebs	5.617s
?   	github.com/hashicorp/packer-plugin-amazon/builder/ebs/acceptance	[no test files]
ok  	github.com/hashicorp/packer-plugin-amazon/builder/ebssurrogate	2.065s
ok  	github.com/hashicorp/packer-plugin-amazon/builder/ebsvolume	1.657s
ok  	github.com/hashicorp/packer-plugin-amazon/builder/instance	2.584s
ok  	github.com/hashicorp/packer-plugin-amazon/datasource/ami	1.382s
ok  	github.com/hashicorp/packer-plugin-amazon/datasource/parameterstore	1.011s
ok  	github.com/hashicorp/packer-plugin-amazon/datasource/secretsmanager	0.606s
?   	github.com/hashicorp/packer-plugin-amazon/post-processor/import	[no test files]
?   	github.com/hashicorp/packer-plugin-amazon/version	[no test files]

Closes #314

[hashicorp-cla]

All committers have signed the CLA.

[lbajolet-hashicorp]

Hi @ccravens,

Thanks for the PR! The code overall looks good to me, I left a couple of nitpicks on the docs and the changes to the code documentation, while linting is appreciated, in this case since it is intertwined with the proposed enhancement, I think this is detrimental to the comprehension of the change, and therefore suggest that this is moved to a separate PR so we can independently take a look at it.

Aside from that, I see that the ebs builder is left out of this PR, I presume since it does not use the RegisterAMI API call to finalise the AMI creation. This is not the first time a feature is left out for this specific builder unfortunately, I think we should track this work independently, and refactor the logic for all builders so they're on an equal footing regarding this method to create AMIs.

If anything regarding testing, while this won't work locally completely, I would suggest adding an acceptance test to ensure the feature works as expected. We don't have anything for builders like chroot or instance, but we do have an acceptance test structure for ebssurrogate.
Since this involves creating resources (and using IAM roles that are permissive in the environment tests are run), I understand if this is not something you want to do, in this case let me know, and I will take some time to do this in the coming days.

Pre-approving the PR for a later merge, I will circle back on it when you have addressed my comments.

Thanks again for the contribution!

[lbajolet-hashicorp]

The doc snippet looks good to me, for completeness I'd suggest adding this to all the builders that support the feature, so in addition to the chroot builder, the ebssurrogate and the instance builder docs should add this to their sections.

[lbajolet-hashicorp]

This is added to the post-processor here, but I don't see the related step being updated, is this voluntary?

[lbajolet-hashicorp]

While I generally am not against using a linter for cleaning-up files, in this case, updating the documentation feels out of the scope of this PR, and makes the diff harder to read.
Could you please leave the doc changes out of this PR? If you think they are relevant, maybe open a separate PR for us to review, so this doesn't become a blocker for this one?

[lbajolet-hashicorp]

Superseded by #379