feat(misconf): Add --disable-causes flag

[simar7]

Description

Adds a new flag --disable-causes to disable cause output on demand.

Before

LOW: container should drop all
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Containers must drop ALL capabilities, and are only permitted to add back the NET_BIND_SERVICE capability.

See https://avd.aquasec.com/misconfig/ksv106
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 test/testdata/kubernetes/optional/KSV035/denied.yaml:7-8
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   7 ┌     - name: hello
   8 └       image: blah/something
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

After

LOW: container should drop all
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Containers must drop ALL capabilities, and are only permitted to add back the NET_BIND_SERVICE capability.

See https://avd.aquasec.com/misconfig/ksv106
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Related issues

• Partially addresses perf(misconf): High memory usage (9.5 GB) and long scan time (45 min) on some repos #6557

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

As I commented in #6557 (comment), it doesn't make sense to me to consume a lot of memory just to parse a line from files with a misconfiguration. So rather than adding a new flag without knowing the cause, I think the priority is to find out the cause of memory consumption and solve that problem. If the only way to solve this problem is to disable causes, then we should add the flag. What do you think?

[simar7]

As I commented in #6557 (comment), it doesn't make sense to me to consume a lot of memory just to parse a line from files with a misconfiguration. So rather than adding a new flag without knowing the cause, I think the priority is to find out the cause of memory consumption and solve that problem. If the only way to solve this problem is to disable causes, then we should add the flag. What do you think?

Yes this is a two step approach. IMO we need both.

1. Identify the root cause of high memory usage
2. Provide the option to turn off the causes as a flag

This PR addresses point 2. It's still in draft. Hence I mentioned that it only "partially addresses" the problem.

As for Point 1, I have identified where the issue is and I'm working on a separate PR to address that. The issue is how we parse each file as can be seen below from a heap capture.

Feedback welcome.

[knqyf263]

As you described in #6586, addressing point 1 drastically improves the performance. Do we still need a new flag for point 2? Taking 2 mins on a huge repo is fair enough, IMHO.