Add resource container selector resolver

[mpkorstanje]

Overview

Resolve resource container selectors

As a follow up for #3630 and #3705 this adds a
addResourceContainerSelectorResolver()
method to EngineDiscoveryRequestResolver.Builder analogous to
addClassContainerSelectorResolver().

Points of note:

• As classpath resources can be selected from packages, the package
  filter should also be applied. To make this possible the base path of
  a resource is rewritten to a package name prior to being filtered.

• The ClasspathResourceSelector now has a getClasspathResources
  method. This method will lazily try to load the resources if not
  already provided when discovering resources in a container.

• selectClasspathResource(Set<Resource>) was added to short circuit the
  need to resolve resources twice. And to make it possible to use
  this method as part of the public API,
  ReflectionSupport.tryToLoadResources was also added.

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[marcphilipp]

So the problem I have been running into is that:

1. Resources are only uniquely identified by their URI.

2. Resources are not uniquely identified by their name. Searching a container may return multiple results that need to be de-duplicated in some fashion.

3. Resources are uniquely identified by their name and module name. So searching a module yields theoretically unique resources.

4. Resources discovered in a container should also be discoverable using the resource selector.

Currently, there are two options: ClasspathResourceSelector and UriSelector. Using the former with a non-unique name/path would result in all resources for that name/path being discovered. In that case, one could use a DiscoveryFilter to exclude those that are not wanted, e.g., based on parts of the URI. Using the latter would work (assuming the engine in question supports UriSelector for resources).

We briefly discussed the problem in the team. Do you have a concrete use case that would require solving the problem of having a machine-independent identifier for re-running a test based on a non-unique classpath resource? Otherwise, maybe we can move forward as-is and see if it actually becomes a problem?

[mpkorstanje]

We briefly discussed the problem in the team. Do you have a concrete use case that would require solving the problem of having a machine-independent identifier for re-running a test based on a non-unique classpath resource? Otherwise, maybe we can move forward as-is and see if it actually becomes a problem?

Haven't got any concrete examples in mind right now. So that seems reasonable.