feat(samples): add local generation for crypto keys

[FrodoTheTrue]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

[busunkim96]

Is it reasonable to expect that customers looking at this customer will already have a public key and/or know of a good way to generate one?

If not, or if there are best practices you'd like to show it may be worth pulling the key generation code up into the sample.

Showing that it's possible to use Cloud KMS to create a key also seems valuable to me - maybe you could keep the KMS sample link in the comments?

[FrodoTheTrue]

I returned comment about Cloud KMS way.

The reasons why we prefer to generate keys locally:

Keys stored in Cloud KMS are not directly exportable, so the only way a customer can use them is by calling the AsymmetricSign/Verify and Encrypt/Decrypt APIs on those keys
however, this suffers from two problems:

• most applications that need to use the certificate/key don't support accessing the key like this, but instead require direct access to the key on the filesystem.
• even if they did support that, this would likely introduce too much latency and limit the throughput, so there aren't many scenarios where this would be useful

Leaf certificate keys are almost always generated directly on the machine that will be using them, and never sent anywhere else.