Deprecate godep in favor of Go Modules (new official dep. mgmt. tool)

[mrutkows]

Please switch and document for developers how to use/build with "Go Modules"; see
https://github.com/golang/go/wiki/Modules
https://levelup.gitconnected.com/switch-to-go-modules-from-go-dep-fcdd4aa41bd5

Please note that client-go chose to use govendor which has numerous problems: for reference: https://github.com/apache/openwhisk-client-go/pull/113/files

[markusthoemmes]

Why not go modules? All other golang dependency management tools are afaik deprecated in favor of it.

[style95]

I also have felt the project structure of OpenWhisk cli families(client-go, cli, wskdeploy) is somewhat different from the other Go projects and I have wondered the reasons.

[mrutkows]

@markusthoemmes i am open to whatever the "approved" toolchain from GoLang... I will read up on go modules, but had seen other Google lead projects using "dep" and had only read blogs indicating "dep" was the latest/approved dep. generator/updater for Go. Thanks for the info!

[mrutkows]

@style95 @markusthoemmes my main concern was that ALL our client-side tooling projects that are based on GoLang (CLI, client-go and wskdeploy) all use the same (and latest approved dependency tooling) and each did not each use different ones that were chosen "ad hoc" and had different pitfalls. This was a direct response to a PR in go-client that I merged that had a bogus vendor.json file with tons of invalid dependencies and was dismayed to see no uniformity.

[markusthoemmes]

Go modules is definitely the way to go. All projects still on dep are only there because they have some legacy considerations and/or don't want to switch yet cause it has an impact.

If you need to switch tools anyway, definitely go with go modules.

[mrutkows]

Any PR should be coordinated with similar Issue/requirement in wskdeploy:
apache/openwhisk-wskdeploy#1082