Update relevant auto-configurations to ConditionalOnSingleCandidate

[snicoll]

Now that we have a special support for "single candidate" in #1702 we should review our auto-config infrastructure and update conditions accordingly. Anything that configures some sort of template is directly targeted at this.

[snicoll]

It's a bit more complicated than I thought since we need to isolate such code in separate @Configuration and order them in such a way that the bean it's checking is already created. The Rabbit/JMS configuration is significantly harder to write unless we move the template config to a separate auto-configuration. Thoughts?

[snicoll]

We really should find a way to make this work. This would allow boot to back off when several instance of a given type is defined rather than blowing up like it does currently. #4678 is another occurrence of this problem.

[philwebb]

Let's talk to @jhoeller about this to see if we can extend the core container support. What we want is a way to plugin strategies to use when multiple candidates are found. Something like

@Bean
@ConflictResolver(MyResolver.class)
public MyBean(MyDep dep) {
}

// ...

public class MyResolver implements ExtendedAutowireCandidateResolver {

    Dunno resolve(List<SomeContext> candidates) {
       /// ...
    }

}

i.e. Similar to the @Condition annotation, the @ConflictResolver creates a resolver instance and is provided with information (including class meta-data). In Boot we would mark auto-configured beans that we create so that we know that is the one to inject.

[snicoll]

I have been discussing this with @jhoeller today and he gave me a few advices to tune the way the configuration can be architectured. This is WIP but the current tests pass for JMS and AMQP using @ConditionalOnSingleCandidate, see snicoll@dd281b0