Add a test for go mod madness

[purpleidea]

Go mod and dependency hell has broken what used to be a really elegant workflow. See here:

https://github.com/purpleidea/mgmt/blob/master/docs/faq.md#why-arent-you-using-glide-godep-or-go-mod-for-dependency-management

I've been sad about this ever since we were forced to give up here: 88516546fa25f3a629dc6729403328b6edc29109

Long-term, I'd love to write some patches to fix the problem, short term, let's work around it.

Your mission should you choose to accept it is:

1) Write a simple shell script that presumably uses some combination of go get, go mod tidy, and whatever other incantations are required to, in an idempotent way, attempt to upgrade every single dependency to the latest git master type equivalents, and remove any old or unused dependency.

In theory for any instant in time, there should be one single valid answer here. I honestly don't know how to do it, I perpetually run a bunch of crappy commands repeatedly to upgrade things, when it should really be one simple go upgrade sort of thing.

This should also remember that tests have dependencies too!

2) Add a new test case to mgmt. It should (a) run this script and if there are no changes to make to go.mod or go.sum it should pass. (b) If should fail if the script itself fails. (c) It should compile mgmt with the new deps of course and fail if the compile breaks.

3) Add this test as an optional test in the github actions. That way we'll have a fourth test there. If it fails, we'll know that we need to run our script to update the go.mod and go.sum files.

Thank you brave warrior.

[1garo]

do you think that maybe this could solve the problem? https://golang.cafe/blog/how-to-upgrade-golang-dependencies.html

[1garo]

I tried the go test all, after go get -u ./... and go get -t -u ./... on other project and they fail, so I don't really know how reliable it is.

[purpleidea]

Unfortunately the solution is more subtle for many edge cases.

[purpleidea]

Running go-mod-upgrade and yet another issue: