Ensure that we use correct version of protoc and its deps

[marquiz]

Split into multiple self-contained commits.

1. Use protoc-specific local install directory
   Makes it possible to cleanly and reliably wipe protoc and it's dependencies without affecting other tools that might get installed under the build/tools dir in the future.
2. Makefile: add check-protoc target
3. Simplify and align the installation of protoc dependencies
   Maintain the versions in go.mod.
4. Makefile: check that we use correct version of protoc and its deps
5. Update auto-generated code

NOTE: Could be submitted as multiple smaller PRs, too, that feels better

[klihub]

Could be submitted as multiple smaller PRs, too, that feels better

@marquiz No, I think this is better this way, as a single PR split to commits. These form a coherent collection which together make sense.

The one question I have (or maybe two or three) is, do we really need to change the tool versions we install and use, do we really need to change them as part of this PR, and if we change them as part of this PR, why don't we sync them with current containerd main/HEAD which is what we have deliberately been doing so far in NRI ?

[marquiz]

do we really need to change the tool versions we install and use, do we

We don't change any tools versions, except for protoc-gen-go which we cannot avoid as now the version comes from go.mod where we already have google.golang.org/protobuf v1.34.1. You can see from the last commit that the effect this is ~nil

[klihub]

do we really need to change the tool versions we install and use, do we

We don't change any tools versions, except for protoc-gen-go which we cannot avoid as now the version comes from go.mod where we already have google.golang.org/protobuf v1.34.1. You can see from the last commit that the effect this is ~nil

@marquiz Okay, so sorry for my stupid questions which I'm asking since I have never tried to manage toolchain dependencies using the tool directive in go.mod. I did a quick read up in the go mod documentation and I'm not sure if I understand this now correctly. But is it so, that if we switch to this then we lose control over which versions of these go tool-managed toolchains we can use. IOW, if there is a new release of any of these which breaks everything for us, then there is no way for us to simply force go / go tool to keep using the previous version which would still work for us ?

[klihub]

do we really need to change the tool versions we install and use, do we

We don't change any tools versions, except for protoc-gen-go which we cannot avoid as now the version comes from go.mod where we already have google.golang.org/protobuf v1.34.1. You can see from the last commit that the effect this is ~nil

@marquiz Okay, so sorry for my stupid questions which I'm asking since I have never tried to manage toolchain dependencies using the tool directive in go.mod. I did a quick read up in the go mod documentation and I'm not sure if I understand this now correctly. But is it so, that if we switch to this then we lose control over which versions of these go tool-managed toolchains we can use. IOW, if there is a new release of any of these which breaks everything for us, then there is no way for us to simply force go / go tool to keep using the previous version which would still work for us ?

Ah okay, so we need to pass the desired version to go get -tool xy.z/zy@foobar...

[marquiz]

Ah okay, so we need to pass the desired version to go get -tool xy.z/zy@foobar...

Yes. BUT, if we now did go get -tool google.golang.org/protobuf/cmd/[email protected] that would downgrade google.golang.org/protobuf in go.mod as we already depend on v1.34.1 of that module. I think it's better/safer/easier just to bump the tool version in this PR.

[marquiz]

The PR is now rebased and updated:

• fixed handling of the PROTOBUF_VERSION variable
• added new commit: Use protoc-specific local install directory
  Makes it possible to cleanly and reliably wipe protoc and it's dependencies without affecting other tools that might get installed under the build/tools dir in the future.

EDIT: #232 is merged so ready for review @klihub @chrishenzie @mikebrow

[mikebrow]

LGTM nit.. squash :-)