[Umbrella] Address golangci-lint v2 formatting issues

[seanlaii]

What would you like to be added:
Applies code formatting changes to resolve linting violations reported by the upgraded golangci-lint v2.

Ref: https://github.com/karmada-io/karmada/actions/runs/14120914184/job/39560873286?pr=6237

Why is this needed:
The following issues stem from new checks introduced in v2, which were temporarily disabled for incremental resolution.
Fix #6237

staticcheck:

• QF1008: could remove embedded field "xxx" from selector (staticcheck). (Decided not to fix, but add comment) Add comment for disabling QF1008 #6295
• ST1019: package "xxx" is being imported more than once (staticcheck). Fix lint issue ST1019 #6289
• ST1005: error strings should not be capitalized (staticcheck). Fix lint issue ST1005 #6290
• QF1004: could use strings.ReplaceAll instead (staticcheck). Fix lint issue QF1004 #6291
• ST1011: var periodSeconds is of type time.Duration; don't use unit-specific suffix "Seconds" (staticcheck). Fix lint issue ST1011 #6296
• QF1003: could use tagged switch on operationResult (staticcheck) Fix lint issue QF1003 #6292
• QF1001: could apply De Morgan's law (staticcheck) Fix lint issue QF1001 #6297
• ST1000: at least one file in a package should have a package comment (staticcheck) Add comment for disabling ST1000 and package-comments #6299

revive

• package-comments: should have a package comment (revive) Add comment for disabling ST1000 and package-comments #6299

[seanlaii]

/assign

[seanlaii]

Hi @RainbowMango , @XiShanYongYe-Chang , and @zhzhuang-zju ,

Looking at the staticcheck ST1000 and revive package-comments errors, it seems fixing them involves adding comments to the packages across the entire project. This represents a substantial amount of work.
I wanted to raise the question of whether we should prioritize fixing these right now, or perhaps exclude them.
Happy to hear your thoughts on this.

[RainbowMango]

This represents a substantial amount of work.

Yeah, that's a concern.

I think we can disable this check for now. Currently, most of the packages are primarily for internal use within the project and are not intended to be public packages. In the future, if/when we need to provide public packages for developers, we can move some packages to a separate repository and revisit adding package comments at that time.