Adding pkeyutl tool to the CLI

[smittals2]

Description of changes:

Add pkeutl tool with:
-help
-in
-out
-sign
-verify
-inkey
-sigfile
-pubin
-passin (awaiting #2555 to flesh this out)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 58.63309% with 115 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.64%. Comparing base (f10416a) to head (53e5039).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
tool-openssl/pkeyutl.cc	63.38%	67 Missing ⚠️
tool-openssl/pkeyutl_test.cc	49.47%	48 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2575      +/-   ##
==========================================
- Coverage   78.73%   78.64%   -0.09%     
==========================================
  Files         645      647       +2     
  Lines      110626   111022     +396     
  Branches    15644    15706      +62     
==========================================
+ Hits        87101    87315     +214     
- Misses      22824    23010     +186     
+ Partials      701      697       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[justsmth]

The msys2/ucrt64 CI failures seem related:

tool-openssl/tool_openssl_test failed to complete: exit status 0xc0000005

A "0xc0000005" exit status seems to be associated with memory access violations on Windows.

[smittals2]

The msys2/ucrt64 CI failures seem related:

tool-openssl/tool_openssl_test failed to complete: exit status 0xc0000005

A "0xc0000005" exit status seems to be associated with memory access violations on Windows.

Yea I've been trying to debug why we see this. Before opening the file, we stat it to make sure it exists. In this particular use case, the file is created by the test harness, opened via BIO APIs and populated by the pkeyutl tool, and then fails when we try to read the file subsequently to validate it's contents. I added additional explicit instructions to close any BIO handles that may create resource contention but continued seeing this error.

We can see this in the logs here:

> DEBUG: ReadFileToString - Starting for path: C:\Users\RUNNER~1\AppData\Local\Temp\aws91A.tmp
> DEBUG: ReadFileToString - Checking if file exists with stat()
> DEBUG: ReadFileToString - File exists, size: 32 bytes
> DEBUG: ReadFileToString - Opening file stream
> tool-openssl/tool_openssl_test
> tool-openssl/tool_openssl_test failed to complete: exit status 0xc0000005

We also only see this access violation in msys2 ucrt64 - (Ninja/MinGW) builds. For example msys2 ucrt64 with MSYS Makefiles doesn't fail (neither do any of the other Windows CI checks).

My two pending investigation avenues are as follows:

1. Looking at the Cmake, the two build dimensions we see the error in are special cased:

   aws-lc/.github/workflows/windows-alt.yml

   Line 244 in 1a5b9eb

   - name: Run tests

   . Maybe the diff shell is impacting which libraries our test executable links to
2. Using the BIO APIs to access the same tmp files doesn't cause an issue, but using ReadFileToString which uses the native C++ file reading APIs does, so maybe there's some edge case/bug in these two build dimensions.

[github-actions]

clang-tidy made some suggestions

[github-actions]

warning: variable 'bytes_read' is not initialized [cppcoreguidelines-init-variables]

Suggested change

	int bytes_read;
	int bytes_read = 0;

[justsmth]

2. Using the BIO APIs to access the same tmp files doesn't cause an issue, but using ReadFileToString which uses the native C++ file reading APIs does, so maybe there's some edge case/bug in these two build dimensions.

I suspect the issue might be that it's linking to the wrong C++ runtime when the test runs.

I have a couple of ideas we could try to debug these tests:

• echo $PATH prior to test execution to verify "/ucrt64/bin" is listed first. (The PATH can affect which DLLs get loaded.) We use a "Windows" path above: cygpath -w ${SYSROOT}/bin >> $GITHUB_PATH, but perhaps we should used mixed: cygpath -m ${SYSROOT}/bin >> $GITHUB_PATH
• Run dumpbin /dependents <executable> or dumpbin /imports <executable> to compare executables across the different tests. (Actually, ldd might work in these environments as well.)
• Since the issue seems to be with linking to the C++ standard library, perhaps we could try adding -static-libstdc++ in CFLAGS or something?