Ensure Resolver fulfills the contract of insertHostedCapability

[laeubi]

The TCK for the resolver currently does not check that the contract of ResolveContext#insertHostedCapability is fulfilled what says:

The list returned from findProviders(Requirement), must not be null

This adds the assertion for null (also to findProviders) and that the list passed in was actually ever returned by findProviders and also inserts the hosted capability into the list.

[laeubi]

Excerpts from the spec:

https://docs.osgi.org/specification/osgi.core/8.0.0/service.resolver.html#i3344409

The Resolver can, and likely will, use the returned list to maintain its internal state during the resolve operation while trying out different potential solutions. It can add and remove capabilities at will. The returned list must therefore be mutable and not reused, after it is returned; it becomes owned by the Resolver. However, the Resolver can call back later with the insertHostedCapability(List,HostedCapability) method, giving back the returned list as the first parameter, see Insert Hosted Capabilities.

https://docs.osgi.org/specification/osgi.core/8.0.0/service.resolver.html#i3344346

The Resolve Context must therefore implement an insertHostedCapability(List,HostedCapability) method. The given list must have been returned earlier from a findProviders(Requirement) method invocation. The Resolve Context must find the appropriate position to insert the HostedCapability object, insert it, and return the index of the inserted object.

That's how far the spec goes and what this TCK covers and reveals a flaw in the Felix implementation not following the contract.

What is a bit unclear in the spec, why it does impose this restriction to have the same list passed to the resolve context, one can of course think about that ResolveContext is using a special implementation, but from the first contract the list becomes owned by the Resolver and the Resolver is allowed to modify it at own will and it must never be returned again, it therefore seems a bit odd why not any list should be sufficient. So if this TCK is merged, it would be good to have an additional section describing what are the rationale for this.

[stbischof]

@tjwatson will update the javadoc/spec and describe the less strict behavior