[chore] Use check-latest in actions/setup-go

[pellared]

Avoid problems like this one #4607 by using check-latest-version

Opportunistic improvements:

• use cache-dependency-path when possible
• remove " Setup Environment" steps as they are no longer needed since v3

[pellared]

When check-latest: true is used we can change the go-version values to "1.20" and "1.21". Can I do this (upvote) or do you prefer to still keep the explicit minimal patch version (downvote)?

[pellared]

When check-latest: true is used we can change the go-version values to "1.20" and "1.21". Can I do this (upvote) or do you prefer to still keep the explicit minimal patch version (downvote)?

Done aa526b7

[pellared]

Now the lint job is ~1 min faster 💪 (maybe it was just luck, but I think it should be in average faster)

main 5m 14s
PR 3m 54s

[MrAlias]

When check-latest: true is used we can change the go-version values to "1.20" and "1.21". Can I do this (upvote) or do you prefer to still keep the explicit minimal patch version (downvote)?

I would rather keep the minimums pegged above versions with CVEs. This will help ensure no issues are re-introduced.

[pellared]

When check-latest: true is used we can change the go-version values to "1.20" and "1.21". Can I do this (upvote) or do you prefer to still keep the explicit minimal patch version (downvote)?

I would rather keep the minimums pegged above versions with CVEs. This will help ensure no issues are re-introduced.

@MrAlias, what do you mean by re-introducing? A regression bug that we remove check-latest: true? If this would happen we would simply add it back.

Is your intention that we bump the version each time a Go patch is released? If so then why maybe we should be pinning to the Go version instead e.g. `go-version: "1.21.3"? This would give the advantage of having more reproducible builds.

[pellared]

Merging as at least the CI is quicker. I created #4639 for potentially addressing #4617 (comment).

[MrAlias]

I would have appreciated it if all feedback was addressed prior to this merging, in accordance with our policy.

[pellared]

I would have appreciated it if all feedback was addressed prior to this merging, in accordance with our policy.

1. It was not clear that it isa blocker feedback (there was no "request changes").
2. There was no consensus as @MadVikingGod upvoted my proposal.

I found it more beneficial to merge as it is and created an issue as part of addressing the feedback. I had no bad intentions 😉