Fixes StackOverflow in JavaDetectionEngine:resolveValues

[san-zrl]

Fixes #525. This is a bug in sonar-cryptography 1.6.1. It causes the CBOM generation to fail and thus breaks our CI pipeline. CBOM generation temporarily disabled.

1. Added a tracker in JavaDetectionEngine:resolveValues that ends the recursion and exits the method if the symbol has been visited before.
2. Changed repetitive log msg "Detected constructor definition has more then one argument..." to trace.

[n1ckl0sk0rtge]

Hi @san-zrl, thanks for tracking this down — the visited set is pointed at exactly the right method.

I dug into #525 as well and submitted the recursion fix in its own PR with a red-green test: #530. The test reproduces the exact alternating stack trace from the issue (a field initialized from another field, plus an assignment back). I would like to have a test for this behavior. Two notes on the difference to this PR:

1. The visited set here is never released. Once a symbol is in the set, it stays there for the whole resolution. Two sibling branches that both go through the same shared variable (for example two array elements) then lose the second value. fix: stop endless recursion in resolveValues on assignment cycles #530 removes the symbol again in a finally block, so only real cycles are cut. The test also checks that the value still resolves through the cycle to the constant.
2. Root cause of the flood: since e1fdab3 the engine resolves the arguments of every method call (for the detached call records), not only matched crypto calls. That is why both the recursion and the log noise only showed up in 1.6.1.

Suggestion to keep the pieces easy to review:

• Cut this PR down to the log-noise fix (the LOGGER.info → trace change). That part is not in fix: stop endless recursion in resolveValues on assignment cycles #530 and is a good fix on its own.
• Put the maven.yml change (disabling the CBOM step) into a separate PR, so the fix or removal of that CI step can be discussed on its own.

Happy to hear what you think.

[san-zrl]

Hi @n1ckl0sk0rtge - makes sense. If I re-enable the CBOM generation the build for this PR will fail. But this is okay, since only the trivial log change is left.

[san-zrl]

I'll close this PR an file another with log change.