chore: explicit revive rules

[mmorel-35]

Description

This list all default rules and a bit more.
It keeps disabled the rules that are not yet applied

[knqyf263]

While it looks good to me, I cannot accept it alone since it affects the whole project. I like this change as I prefer less nesting, but this depends on the developer's preference. What do you think? @aquasecurity/trivy

One thing to note is that early return may not be equivalent to if-else. For example, in the following case, pkg is scoped in the if-else statement.

if pkg, ok := pkgs[vuln.PkgID+vuln.PkgPath]; !ok {
	continue
} else {
	r.Results[i].Vulnerabilities[j].PkgIdentifier = pkg.Identifier
}

However, pkg will be alive outside the if scope in this case.

pkg, ok := pkgs[vuln.PkgID+vuln.PkgPath]
if !ok {
	continue
}
r.Results[i].Vulnerabilities[j].PkgIdentifier = pkg.Identifier

As far as I could review, none of the changes seemed to be affected by this change in scope, but in some cases, it may need to disable the linter with nolint. Just sharing.

[mmorel-35]

There is a preserveScope argument to normally adress your concern except if I'm missing the point

[DmitriyLewen]

LGTM

[DmitriyLewen]

it's not related to the linter
But it looks like there's a bug here and there should be a warning, like in other cases. For example:

trivy/pkg/rpc/convert.go

Lines 111 to 113 in 40f4c06

	if err != nil {
	log.Warn("Custom resource conversion error", log.Err(err))
	}

maybe we can fix this right away?
cc. @knqyf263

[knqyf263]

I also noticed and accepted the change as the function doesn't return an error. But yes, you're right. I forgot about the idea of showing warnings. We should warn it.

[simar7]

I actually prefer inlining if conditions to reduce nesting and lines of code, however this is subjective. But as @knqyf263 pointed out, (not this particular instance) it may lead to subtle errors. And as you mentioned, to suppress them either we'd have to add preserveScope argument or /nolint.

Based on that is it still worth to add this rule?

[DmitriyLewen]

I prefer not to reuse the variable name inside if-else (for me it is more readable code)
e.g.:

pkg := Package{name: "foo"}

if p, ok := pkgs["bar"]; ok{ // for this case i don't use `pkg`. I will use `p`, `foundPkg`, etc.
...
}

so in my case these changes will not lead to consequences.
but this is just my opinion

[mmorel-35]

Let’s narrow this to list rules and disable those not already applied. so each rule can be discussed and enabled one at a time.

[knqyf263]

There is a preserveScope argument to normally adress your concern except if I'm missing the point

It's nice! Thanks for sharing.
Actually, I was wondering if the linter already takes scope into account since no scope change had an adverse effect despite the numerous changes in your PR.