Add the active crypto backend to build info (go version -m app)

[dagood]

• Resolves Add debug.BuildSetting entries corresponding to crypto backend usage #963
  • There is a different mechanism we could use (see comment on #963) but I think this probably the way to go.

This change makes it easier to tell what backend a program ended up being built with by adding lines like cryptobackend=openssl to the build info key-value pairs:

$ GOEXPERIMENT=systemcrypto go build . && go version -m exp
exp: devel go1.21-a011bc5ece Mon Jul 3 13:03:24 2023 -0500 X:systemcrypto
        build   GOEXPERIMENT=systemcrypto
        build   GOOS=linux
        build   cryptobackend=openssl
... [more pairs above and below this output]

$ go build -tags=goexperiment.systemcrypto . && go version -m exp
exp: devel go1.21-a011bc5ece Mon Jul 3 13:03:24 2023 -0500
        build   -tags=goexperiment.systemcrypto
        build   cryptobackend=openssl
...

$ GOOS=windows GOEXPERIMENT=systemcrypto go build . && go version -m exp.exe
exp.exe: devel go1.21-a011bc5ece Mon Jul 3 13:03:24 2023 -0500 X:systemcrypto
        build   GOEXPERIMENT=systemcrypto
        build   GOOS=windows
        build   cryptobackend=cng
...

Note that X:systemcrypto shows up when using GOEXPERIMENT, but -tags doesn't show up there. The -tags line only shows up when the -tags flag is used for go build. Technically, someone (or a program) can look for these signs and figure out what the program is using by understanding the build logic, but this could be fairly fragile. Instead, we can include the info directly.

buildinfo was added in 1.18.

The built-in pairs are defined at https://pkg.go.dev/runtime/debug#BuildSetting, and I haven't seen any reason we shouldn't add our own pairs. The most likely break I can think of is that an external tool will fail if it sees an unrecognized pair, but it seems more likely to me that it would skip them.

[karianna]

@dagood We intending to keep this PR? I noted it was a year old :-)

[dagood]

I would still argue that we should do this. I think now, it's even more important given #1352 (@qmuntal). We should probably also add some straightforward "used Microsoft Go" data (because there will no longer be an explicit GOEXPERIMENT or tag).