pubsys: Do not allow private AMIs to be published to SSM parameters in the public namespace

[cbgbt]

Description of changes:
This change by default will disallow publishing SSM parameters to the public /aws/ SSM namespace if they refer to private AMIs.

Testing done:

• Here's a sample run where I tried to set some of my own private AMIs to the /aws/service/doggierocket namespace. ( 🐶 )

03:58:05 [INFO] Using AMI data from path: ../../build/images/aarch64-aws-k8s-1.21/bottlerocket-aws-k8s-1.21-aarch64-1.10.0-867fbbda-amis.json
03:58:05 [INFO] Parsing SSM parameter templates from policies/ssm/defaults.toml
03:58:05 [INFO] Ensuring that only public images are published to public parameters.
03:58:05 [ERROR] Attempted to set parameter '/aws/service/doggierocket/aws-k8s-1.21/arm64/1.10.0/image_version' in us-west-2 to '1.10.0', based on AMI ami-0bc2a2c72b2ce0a28. That AMI is not marked public!
03:58:05 [ERROR] Attempted to set parameter '/aws/service/doggierocket/aws-k8s-1.21/arm64/1.10.0/image_id' in us-west-2 to 'ami-0bc2a2c72b2ce0a28', based on AMI ami-0bc2a2c72b2ce0a28. That AMI is not marked public!
Failed to update SSM: Cowardly refusing to publish private image to public namespace without ALLOW_PRIVATE_IMAGES

[ec2-user@ip-10-0-0-27 pubsys]$ echo $?
1

• Using --allow-private-images passes this check (but then fails because we are trying to update parameters that don't exist)

Originally I sought to use Traits and fakes to provide additional automated testing here, but it was pretty difficult to do it in a way that didn't require more significant refactoring.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[stmcginnis]

Looks good to me once the build failure is addressed. Great to have this!

[stmcginnis]

Would it be better to set this at runtime based on the running host's number of cores?

[cbgbt]

Since this is network-bound, I picked an arbitrarily "low" number of concurrent checks. I've found that you often hit throttle limits trying to hit AWS using all of your cores if your host is too beefy. This can be rectified with more careful throttling avoidance, but I opted for a simpler route here.

I should probably clarify why the number was chosen in a comment.

[stmcginnis]

Interesting, I was actually worried this number was too high. I was thinking something like Min(cpu_cores, 16), but even wondering if that should be more like 8 than 16.

[cbgbt]

8 is probably a safer bet!

[cbgbt]

• Fix clippy warning on large size variation in Enum variants
• Lower concurrent AMI query to a safer value to avoid throttling

[yeazelm]

I'm still learning Rust for concurrency things, so I didn't review those specifics, but otherwise it looks good to me.

[etungsten]

Nice! Just have a few non-blocking questions and small suggestions.

[cbgbt]

Addressed @etungsten's feedback

• Cleaned up Option handling when calling EC2 DescribeImages
• Added proper rate limiting to DescribeImages calls via governor crate
• Pre-allocate memory for data structures with known sizes
• linting fixes

licensing issue with the governor crate

[cbgbt]

• Re-added BSD-2-Clause to deny.toml. This license is allowed, it was just previously not used.