Double-check FIPS mode is enabled during FIPS mode test jobs

[dagood]

As of writing, https://github.com/microsoft/go-infra-images/blob/main/src/cbl-mariner/1.0.20211027/fips/Dockerfile sets GOLANG_FIPS=1, so we can use that image to test Go under FIPS mode. If FIPS mode engages but hits a problem (incompatible OpenSSL, bad changes in PR, etc.) we would know because Go would fail tests trying to initialize it.

Potential brittleness that could get through:

• If GOLANG_FIPS=1 is renamed in the prereq image, or somehow not set properly, we wouldn't end up testing in FIPS mode in the Go repo. We'd just be running non-FIPS tests twice.
• If the GOLANG_FIPS env variable is renamed in Go, or somehow not detected properly, we would be in the same situation.

We can manually confirm that FIPS tests are running by looking for "Passed" tests in the CI results UI that only run in FIPS mode, like TestUnreachable in #324 (comment). Our CI should do something like that.

[jaredpar]

Do we suspect it's not running in FIPS now or this is more fear that it could silently regress in the future?

[dagood]

This issue was about preventing regressions, but it looks like we never actually got CI on the fips-enabled infra image. #491 is trying a switchover.

[dagood]

I think a neat way to do it would be this:

1. Make a tool in go-infra, say github.com/microsoft/go-infra/cmd/checkfips
2. Have the tool create a temp Go program and attempt to compile it with a given go binary (defaulting to the one that's available in PATH) to determine if that copy of Go supports the boring/FIPS APIs. (This determines if the boring standard library changes are present.)
3. The tool then runs it--the temp program outputs whether the machine is in environment-driven FIPS mode, and also whether attempting to force-enable FIPS works or if it results in an error.
4. Give checkfips some flags that make its exit code 1/0 depending on what the situation is, so it's very easy to use for an automated test.

Then we can use this tool during microsoft/go CI without having to maintain the tool itself in each branch (just a module dependency), and broader users of our toolset have an easy way to verify they got the right build of Go and that their environment supports FIPS in the way they expect.

[dagood]

Note from Go sync, @qmuntal I think this was your suggestion but correct me if I'm wrong: 😄
For a real-world-ish end-to-end test, we can build/run a test app in FIPS mode that tries to do something that is not supported while in FIPS mode (which is probably different for our Linux and Windows implementations), and make sure it fails.