Don't include more bundles if the requirement is already fulfilled

[laeubi]

Currently PDE includes everything wired in the target platform even though a requirement might already be fulfilled and only has single cardinality.

This now tracks all capabilities provided and check if a single cardinality is already fulfilled by some of the bundles chosen.

Fix #1604

@HannesWell something for RC1?

[github-actions]

Test Results

   285 files  ±0     285 suites  ±0   49m 12s ⏱️ +44s
 3 608 tests ±0   3 532 ✅ ±0   76 💤 ±0  0 ❌ ±0 
11 016 runs  ±0  10 785 ✅ ±0  231 💤 ±0  0 ❌ ±0 

Results for commit 90a2b9a. ± Comparison against base commit 975f72b.

[HannesWell]

The problem that a product only contains a sub-set of all bundles in the TP and that therefore the wiring can be different than in the TP is something I thought about a while ago.
While filtering out already provided capabilities as you suggested should have the desired effect (since it's performing a breath-first-search through the complete wiring to compute the closure), I'm not sure if there are cases where just skipping capabilities and thus bundles could break something (plus we have the potential performance problem described below).

When I thought about this general problem, the solution alternative solution I found was to create a new state/wiring resolution for the launch where the bundles explicitly listed in the product (directly or through feature containments) are the 'roots' and are therefore preferred by the resolver. But I havn't checked if it's possible to define such 'roots' or maybe adding them first is already sufficient?

@HannesWell something for RC1?

Better not, as this area has been shown to contain surprises in the past that one doesn't really expect.

[HannesWell]

This will increase the runtime characteristics of the collection of dependencies by one or two orders (depending on the reference) as for each single requirement the entire namespace is searched again. And namespaces like osgi.wiring.package or osgi.wiring.bundle the namespace is huge, basically all packages or bundles available reside their and it would be checked with a linear search for each single-requirement.

To mitigate that this check should either exclude certain known large namespaces like package and bundle that we are usually not interested anyways (ok, well excluding duplicates could also be interesting for bundles/packages).
Or by introducing a second look-up level that includes the bundle/package name, but I think that's not trivial just on general requirements/capabilities as one has to decompose the filters.

[laeubi]

I don't think that skipping anything is possible here and yes the problem is "hard" but doing a full resolve could even be harder.

We do similar thing on Tycho and even for very large sets of metadata this has never shown any performance problem as this are very simple comparisons.

[laeubi]

I'm not sure if there are cases where just skipping capabilities and thus bundles could break something

I can't think about it right now, but the users always has the chance to influence "the roots" (but can't exclude things what leads to the problem described here).

Basically this is how Tycho/P2 works when building a product, first include the roots and then everything what is required from there (just that it uses deep first if I rember correctly).

But I havn't checked if it's possible to define such 'roots' or maybe adding them first is already sufficient?

This is what actually is the resolver service of OSGi for, but don't expect it to be more efficient, I use such think in the PDE>BND integration in Tycho already so it is possible.