Bump golangci-lint to support 1.23

[okokes-akamai]

We use 'stable' in our Github Actions and that now refers to Go 1.23, so we need a supported version of golangci-lint for that one to work.

General:

• Have you removed all sensitive information, including but not limited to access keys and passwords?
• Have you checked to ensure there aren't other open or closed Pull Requests for the same bug/feature/question?

Pull Request Guidelines:

1. Does your submission pass tests?
2. Have you added tests?
3. Are you addressing a single feature in this PR?
4. Are your commits atomic, addressing one change per commit?
5. Are you following the conventions of the language?
6. Have you saved your large formatting changes for a different PR, so we can focus on your work?
7. Have you explained your rationale for why this feature is needed?
8. Have you linked your PR to an open issue

[okokes-akamai]

Oh... it seems to have worked, it was just slow (as it was the first run). https://github.com/linode/linode-cloud-controller-manager/actions/runs/10399222522/job/28797786593

[okokes-akamai]

I'd rather move golangci-lint to tools.go and go.mod, so that dependabot handles this automatically.

[rahulait]

Since this has already been updated in main branch and we are now using golangci/golangci-lint:latest, can we close this PR?

[okokes-akamai]

@rahulait we're using latest? That sounds like a bad idea that will only introduce problems after an upstream release breaks our build.

[rahulait]

If upstream breaks, we can easily pin to an older release for getting past linting errors. Do you think its better to pin to a fixed version or use go.mod and have dependabot update it whenever required? We can take that approach as well.

[okokes-akamai]

The issue is that if it breaks, it just breaks over time and all existing PRs and nightly builds and whatnot will all be red. I don't think we need to go all the way to go.mod pinning, but we could just pin it in the job itself and use dependabot to track it.

[rahulait]

I am hoping this will address the issue: #278
Let me know if this is not what we wanted.

[okokes-akamai]

Great!