Support Go Modules

[SamWhited]

Attempting to support modules for containerd projects. Specifically this PR adds a go.mod file for this repo and updates the vendor validation script to support go modules alongside vndr by checking for the presence of vendor.conf and using vndr if it exists or go mod vendor if it does not.

[estesp]

Sorry that we hadn't removed the release-tool from this repo yet; I just opened a PR #27 to correct this. Can you move this work to the new release-tool repo?

[SamWhited]

Sure thing, as soon as your PR is merged I'll remove everything from this PR except the validation script fix, and then after that's merged I can update the release-tools repo to use Go Modules.

[SamWhited]

Done, PTAL.

[dmcgowan]

This was the previous method used in some PRs and we suggested adding here #26

[SamWhited]

Adding tidy sounds good, but we probably don't want to check the value of GO111MODULE because "on" will be the default value when Go 1.14 is released and if it's defaulting to on it still won't show up in go env GO111MODULE. It could also be set to auto and we could be outside of GOPATH in which case we may still want to use module mode. Since this is repo specific I don't think we can depend on an environment variable, but the go.mod file being present (or the lack of a vendor.conf file) is probably a good indicator that we intended to use modules with this repo.

EDIT: Added go mod tidy as well.

[estesp]

This method seems to make sense to me, and helps have an easy "switch" for transition--when the vendor.conf is removed from a repo, you get automatic enablement of the go mod checks.

[estesp]

LGTM

[kzys]

I thought we would have a transition period where we still use vndr but make sure go mod is working. Dependencies like gotest.tools should be updated before adding go.mod.

If we don't have the transition period, we can just use either vndr or go mod, as this PR proposed.

[SamWhited]

A transition period seems like you'd just wind up with the vendor.conf and go.mod being out of sync somehow, then when you switch over fully to go.mod you accidentally downgrade a dependency. You would possibly also want to add a test that always checked that they were in sync on each PR to make sure this didn't happen by mistake.

This seems like a lot of work to me instead of just upgrading repo-by-repo to go.mod.

[dmcgowan]

Sure, let's try this approach, it seems very reasonable and requires no extra configuration from the caller.

LGTM