switch out golangci-lint with more basic linting

[jakecoffman]

I am frustrated with golangci-lint which runs a number of linters on the code, so I'm switching it out for more basic and standard linting. Here is my list of grievances:

When running locally it seems to run on the standard library? and fails?!

../../../../usr/local/go/src/net/interface.go:233:13: zoneCache.RUnlock undefined (type ipv6ZoneCache has no field or method RUnlock) (typecheck)
                zoneCache.RUnlock()

It's also giving false positives about something that compiles ok:

cmd/dependabot/internal/cmd/update.go:143:12: undeclared name: `yaml` (typecheck)
                if err = yaml.Unmarshal(data, &input); err != nil {

Additionally in #65 it suggests something that doesn't compile, possibly because generics are not supported by gocritic?

replace `*new(T)` with `T(nil)` (gocritic)

So I'm trying to use the builtin tool go vet and use the standard gofmt to ensure that basic things are correct, but avoid the false positives and some of the nit-picky linting that golangci-lint runs. I think at this point it's just more trouble than it's worth.

[jakecoffman]

Also forgot to mention I attempted to ignore the error in #65 but I can't get the ignore syntax correct? This is just more messing with linting than I want to do! 😅

[deivid-rodriguez]

I know nothing about go, but linting should be helpful but not get in the middle.

[jeffwidman]

Weird, I've generally been pretty happy with golangci-lint and never experienced any of these sorts of issues other than it has taken the entire tooling ecosystem a while to add support for generics.

There's actually a lot that I found it added beyond govet / gofmt, so it might be worth circling back on this six months down the road and see if those issues are fixed (or can identify/fix the misconfiguration that I suspect may also be happening here). But no sense wasting cycles on that right now.