go version should inform that the go binary is generated by microsoft

[qmuntal]

The go version is used to know which is the version of go binary being used and it can also discover which go version was used to generated a binary. This version is taken from a VERSION file in the root dir, and if it does not exist it is generated on the fly following this logic: https://github.com/golang/go/blob/577287728a8e8abbcbc6c96fdd49feb5a99ced0c/src/cmd/dist/build.go#L348

For example, running go version on my computers it outputs go version devel go1.18-505a7c80f2 Wed Nov 3 18:06:56 2021 -0500 windows/amd64.

We should include Microsoft-specific information in that output, such as the microsoft tag and probably a AzDO build number (when doing intermediate releases).

I propose to do it as follows:

• microsoft/main does not have any committed VERSION file.
• Our builders will generate on-the-fly with whatever pattern we decide IF the VERSION file does not exist. This auto-generated file will contain at least a microsoft tag and the AzDO build number.
• We will commit a hand-made VERSION file on every release branch with at least the microsoft tag and the released version number.
• boringcrypto and openssl branches will have a special tag that clearly identifies them

This approach has the nice property that no upstream code has to be modified as all the logic will be put on microsoft/go-infra.

(Forked from #140)

[dagood]

• We will commit a hand-made VERSION file on every release branch with at least the microsoft tag and the released version number.

I think we should probably still use a tool to do this, because upstream commits a VERSION file in the release branch as soon as it forks from master and updates with each servicing release, so our changes would end up causing merge conflicts, down the line.

I actually already put in a way for the Docker infra to detect when we have a MICROSOFT_REVISION file, and I think we can use that file for this, too: https://github.com/microsoft/go-infra/blob/68061e82f4f22d60f65402d6d1fa2c5590586f12/buildmodel/buildassets/buildassets.go#L70. We can read it (if exists) and combine it with upstream's VERSION file to make e.g. go1.17.2-1. (Debian-style revision number, in case we need to release more than one build per upstream servicing cycle.) Then the tooling can also add the same Microsoft prefix and other info we'd normally add in microsoft/main.

We should ideally set up our upstream sync tool to reset MICROSOFT_REVISION to 1 whenever VERSION increments, so we automatically go from 1.17.2-5 to 1.17.3-1, rather than 1.17.3-5. (Once we build 1.17.3-5, it may be too late to go back, depending on how people use our versions.) But, it's only a "brand" issue if we accidentally build 1.16.3-5 and have to continue with -6, so I don't think this part of automation is a high priority.

This approach has the nice property that no upstream code has to be modified as all the logic will be put on microsoft/go-infra.

👍 The approach I looked at in #140 (comment) where I tried modifying the linker itself was way overcomplicated. It's also nice to not even need to modify src/cmd/dist/build.go and deal with risk and potential merge conflicts there.

[dagood]

I noticed something weird about go1.18beta2: the tag https://github.com/golang/go/tree/go1.18beta2 has no VERSION file, but the source archive on https://go.dev/dl has a VERSION file that says go1.18beta2.

It turns out Go's release tooling adds the VERSION file dynamically: https://github.com/golang/build/blob/1446634696dbe6e4c58d9b2c29cd176fc94cc915/cmd/release/release.go#L383

This seems to me to reinforce that this is the right thing for us to do, too.