Add hook-point to exclude imported configuration classes

[snicoll]

Spring Boot has an optimization in which a DeferredImportSelector implementation has a chance to look at an index to remove auto-configuration classes that do not match conditions that can be evaluated early (typically, @ConditionalOnClass). This has the net effect of removing the FQN for each non matching candidate so that the class isn't even loaded while still making sure the auto-configuration report contains an entry for it.

Unfortunately, this arrangement does not extend to configuration classes that are imported as a result of processing an auto-configuration. A large number of auto-configurations are enabled with minimal assumptions, followed by all supported combinations in a form of an isolated @Configuration class, each having their own conditions. Extending this mechanism to "sub-imports" would skip a fair amount of configuration classes, depending on the classpath of the application.

Concretely, everything happens in ConfigurationClassParser. When processConfigurationClass kicks in, members are evaluated for a @Component (that could be configuration classes in the form of inner classes, a very common setup in Spring Boot) and @Import annotations are processed. This method currently misses some form of "owner" (or the component that required the scan).

If we had such argument, we could check if the owner implements an additional strategy interface, something like

interface ConfigurationClassFilter {
	
	boolean filter(String configurationClassName);
}

On the Spring Boot side of things, we could make sure our DeferredImportSelector implements this interface as well and filter the class argument the same way it does early on when looking at the list in META-INF/spring.factories.

[jhoeller]

I got a complete implementation based on a Predicate<String> getCandidateFilter() method on ImportSelector, defaulting to a null return value. This works for me in some local tests to play with; I suppose I'll commit this to master tonight in order to be picked up on Boot's side, refining it from there.

[jhoeller]

Ended up with Predicate<String> getExclusionFilter() for clearer intentions since it's really a candidate exclusion filter.