Current Behavior:

After implementation of #84, grouping different versions or environments into one project is a great feature and improves the overview in the project list. But it has one drawback: You now need to expand a project to see the current issue count, if the project is just a "meta"-level to group versions or sub-projects.

Proposed Behavior:

When selecting a project Classifier, there could be an option like "Project Collection". This would be applied to intermediate versions like "Project X - Android App" (containing multiple versions as children) or "Project X - Server" (containing multiple microservices below).

If "Project collection" is selected, additional configuration shall be shown:
A dropdown to select the "Metrics type", which can be one of:

• Latest uploaded BOM
• Sum of direct children metrics
• Specific child

The UI and API should then prevent upload of BOM and managing components manually for such collection project, and instead show the numbers of its children, according the configuratio. This would give better overview in the UI and allow additional use cases like #657, e.g. by later replacing the component view for collection projects with a metrics view.

The options logic should be:

Latest uploaded BOM
The numbers of the (direct) child for which the BOM was uploaded last shall be shown on the parent. This would be helpful for versioned software, so you can see always the latest versions data on the parent.

Sum of direct children metrics
The numbers of all (direct) children shall be summed up and taken for the parent. This could be interesting, e.g. if you have a meta level "Cloud Project X - Productive environment", with microservices as children, so you see the summary of the complete production environment

Specific child
If selected, offers another input field to select a specific children somehow*. This can be useful in cases where e.g. "Cloud Project X" has direct children for "develop", "qa", "productive" (see above example), so you can always show the "productive" childs numbers on the parent, to focus on them in the views. PROBLEM: If you want to select a child, you cannot do this while creation, and also it would introduce a circular reference. Possible alternative: Define a tag name instead in a textbox input, which is then used to label the child. The first child found with that tag would then be taken.

When calculating numbers with a child, which also is a collection, the numbers calculated for this collection should be taken, not all of its children, like this you can configure yourself a nice hierarchy.

Performance
Live calculation would be a problem for a big project structure. Therefore, the existing vulnerability analysis task should as last step get another step to re-calculate collection metrics. If we have some kind of information about which projects changed during the analysis, we could possibly limit the re-calculation to only trees in which numbers changed.
Additionally, when adding/deleting new sub-projects, changing a sub-projects parent, changing collection configuration or uploading a BOM, (changing a tag if it matches the parents tag configuration if this approach is used), the metrics for the hierarchy above the changed project would have to be analyzed instantly. The results need to be cached.

Considerations to make:

• Need to ensure when calculating metrics for the portfolio, the collection projects are not count, otherwise we would count duplicates
• What if someone doesn't have access to all children projects, but only to a subset? I think if this is the case, he can see the full metrics, even if he only sees a subset. I can think of some controlling having access to top level metrics while not seeing into detailed projects. Also other solutions would not work with cached data.