run go mod tidy

[gregwebs]

There is a lot of junk in go.sum right now. This is because as I understand it, go.sum is only pruned by go mod tidy.
Additionally, we are missing indirect dependencies, which may hamper reproducible builds.

We should add go mod tidy to our CI process.

---

This change is 

[zz-jason]

should we add go mod tidy to the check section in the Makefile?

[tiancaiamao]

I'm fine with the changes, but I'm not sure about the rule:
Should we run go mod tidy every time before pushing the code ?
Or after a GO111MODULE=on go get -u operation ?
Or each time we release a new version ?

What do you think @gregwebs

[gregwebs]

I would prefer to keep it tidy because I like to be able to see transitive dependencies. It is always possible to get the older go.sum from version control. So to verify that it has been run doing it as a check makes sense.
Once it has been tidied, I think it should only change after changing dependencies, so the workflow is to run it after a dependency change.

[gregwebs]

oh, adding it as a make check will make for extra effort because the files may already be changed in the working copy. Checking on CI will be the easiest (run go mod tidy and then see if there are dirty files).

[tiancaiamao]

So, would you like to add this rule in the Makefile, just like the gofmt rule:

tidy:
	@echo "go mod tidy"
	GO111MODULE=on go mod tidy 2>&1 | $(FAIL_ON_STDOUT)

[gregwebs]

Checking stdout/stderr is brittle, particularly for a feature labeled as experimental. On the CI I would run go mod tidy and then run git diff --quiet (should have a zero exit status).

[tiancaiamao]

go mod tidy and then run git diff --quiet is also acceptable, add it to Makefile and update this PR
@gregwebs

[gregwebs]

okay, added. Ironically go.sum is changing daily and keeps conflicting with this branch (precisely what this PR will address).

[tiancaiamao]

LGTM

[zz-jason]

LGTM