Improvements Phase 1: Implement a simple executor service running all scans in parallel.

[devmehtabd]

This PR creates a simple executor service which takes in the value of parallel processors passed in --detect.parallel.processors property and then runs all tasks if the threads are empty.

There are two parts where parallelization is done:

• Scan types are parallelized, with maximum throughput achieved when 6 is passed in as value. (since there are 6 different scan types)
• Wait for Results is parallelized, if customer passes more threads then instead of waiting for results at end, we can immediately start waiting on each scanId which is completed, as an example if package manager scan is finished then we can immediately start waiting on it.

Most parallelization changes are in IntelligentModeStepRunner and ConcurrentScanWaiter class. Other changes are making the lists and sets thread safe that we use commonly between scans. Also logging for diagnostic zip has been updated to reflect thread name to make things clearer for users (The logs will remain dispersed but the thread name will clear the confusion).

As discussed in the grooming meeting, there is no weightage assigned to scan type currently, that will be implemented in Phase 3 of this improvement.

[andrian-sevastyanov]

There are a few recurring themes across most of the futures:

• each future takes care of a tool
• each tool already has some form of callback and we're wrapping these into yet another callback
• catch OperationException / throw RuntimeException
• each future names its thread to something that closely resembles the tool name

This could probably be changed to avoid some of the repetition. Maybe overload the runToolIfIncluded method to take a scanFutures list that takes care of this?

[devmehtabd]

Yeah, thats a good thought, I will give this a try.

[andrian-sevastyanov]

Should we reset the thread names to something else after the tools are done? Or is there no chance of thread reuse with incorrect names?

[devmehtabd]

No, currently there is no chance of thread reuse since before invoking each future, we assign a thread name but I was planning to introduce a global counter in Phase 3 where will have weights assigned to each thread, so reuse is possible there.