golangci-lint: update to v1.49.0

[thaJeztah]

• depends on fix various linting issues in preparation of golangci-lint update #44090
• depends on set ReadHeaderTimeout to address G112: Potential Slowloris Attack (gosec) #44174

Remove the "deadcode", "structcheck", and "varcheck" linters, as they are
deprecated:

WARN [runner] The linter 'deadcode' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [runner] The linter 'varcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter.  Replaced by unused.
WARN [linters context] structcheck is disabled because of generics. You can track the evolution of the generics support by following the https://github.com/golangci/golangci-lint/issues/2649.

- A picture of a cute animal (not mandatory but encouraged)

[thaJeztah]

The remaining ones appear to be legit, but we should review what timeouts we should (and can) set; details about these checks can be found below;

• Add a rule for Slowloris Attack  securego/gosec#807
• Add new rule for Slowloris Attack securego/gosec#809
• RFE: flag uses of top level net/http ListenAndServe(TLS), Serve(TLS) securego/gosec#833
• Detect use of net/http functions that have no support for setting timeouts securego/gosec#842

libnetwork/diagnostic/server.go:96:10: G112: Potential Slowloris Attack because ReadHeaderTimeout is not configured in the http.Server (gosec)
    srv := &http.Server{
        Addr:    net.JoinHostPort(ip, strconv.Itoa(port)),
        Handler: s,
    }
api/server/server.go:60:10: G112: Potential Slowloris Attack because ReadHeaderTimeout is not configured in the http.Server (gosec)
            srv: &http.Server{
                Addr: addr,
            },
daemon/metrics_unix.go:34:13: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
        if err := http.Serve(l, mux); err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
                  ^
cmd/dockerd/metrics.go:27:13: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
        if err := http.Serve(l, mux); err != nil && !strings.Contains(err.Error(), "use of closed network connection") {
                  ^

[thaJeztah]

Oh, fun; bug in the linter? I tried to enable all revive rules, and got this;

INFO [runner/filename_unadjuster] Pre-built 0 adjustments in 423.369909ms 
panic: not enough arguments for cognitive-complexity rule, expected 1, got 0. Please check the rule's documentation

goroutine 7368 [running]:
github.com/mgechev/revive/rule.checkNumberOfArguments(...)
	/go/pkg/mod/github.com/mgechev/revive@v1.2.3/rule/utils.go:171
github.com/mgechev/revive/rule.(*CognitiveComplexityRule).configure(0xc004ac5aa0?, {0x0?, 0x8f0000000131b94f?, 0x1919360?})
	/go/pkg/mod/github.com/mgechev/revive@v1.2.3/rule/cognitive-complexity.go:22 +0x1ad
github.com/mgechev/revive/rule.(*CognitiveComplexityRule).Apply(0xc0003d5ab0, 0xc004d05410?, {0x0?, 0x14?, 0x0?})
	/go/pkg/mod/github.com/mgechev/revive@v1.2.3/rule/cognitive-complexity.go:35 +0x35
github.com/mgechev/revive/lint.(*File).lint(0xc0019457c0, {0xc003926800, 0x44, 0x80}, {0x0, 0x3fe999999999999a, {0x16a6eea, 0x7}, 0x1, 0xc004d05410, ...}, ...)
	/go/pkg/mod/github.com/mgechev/revive@v1.2.3/lint/file.go:105 +0x19b
github.com/mgechev/revive/lint.(*Package).lint.func1(0xc0030f9060?)
	/go/pkg/mod/github.com/mgechev/revive@v1.2.3/lint/package.go:185 +0x85
created by github.com/mgechev/revive/lint.(*Package).lint
	/go/pkg/mod/github.com/mgechev/revive@v1.2.3/lint/package.go:184 +0xac
make: *** [Makefile:251: validate-golangci-lint] Error 2

[neersighted]

LGTM -- is there a lint that can enforce a reason being added to inline linter exclusions?

[thaJeztah]

is there a lint that can enforce a reason being added to inline linter exclusions?

Hmm.. good one; maybe there is 🤔. Actually, I think nolintlint may be able to check for that; https://github.com/golangci/golangci-lint/blob/master/pkg/golinters/nolintlint/README.md

There's a sh*tload of linters in GolangCI-lint https://golangci-lint.run/usage/linters/, and revive itself is becoming more of a meta-linter as well; not all of them are useful to run by default (some very opinionated; good suggestions, but "it depends", so those may be good to run periodically to manually fix up some things).

I'm interested in exportloopref (https://github.com/kyoh86/exportloopref), but I tried it recently, and the specific case where I was hoping it would produce an error, it ... didn't. So I need to look into why not (I think revive now also has some checks for that, so we need to look at overlaps)