Make use of configurer pattern consistent

Spring Boot has introduced the concept of configurer when users would like to create custom instances of a given type whilst retaining the behavior of auto-configuration. They can decide to tune settings before and after calling a configure method. They also can pass a sub-class of the type to configure (if possible) to get exactly what the auto-configuration produced, but with a type that may provide customization of protected methods.

I believe https://github.com/spring-projects/spring-boot/issues/5138 is the issue that started this pattern.

Looking at the codebase, we have used this in other parts but some usage are now inconsistent. Here's a summary of where we are:

• JMS has kept the original idea with a configure method that takes the factory and a ConnectionFactory. The default instance is created by injecting the configurer and calling configure on it.
• Kafka is problematic as a number of customizers are applied manually which means a configure won't do the same thing as the auto-configuration. Users are reporting, for instance, that they lose observability when using this pattern.
• Rabbit:
  • has an extra ContainerCustomizer that is not applied by the configurer.
  • has an extra RabbitTemplateCustomizer that is not applied by the configurer.
  • connection factory setup is also such as that it would take quite a bit of code to replicate it.
• Redis is new and is following the pattern for JMS
• RestClientBuilderConfigurer is sane, with the default builder created by a one-liner from the configurer.
• RestTemplateBuilderConfigurer is sane, with the default builder created by a one-liner from the configurer.

Rabbit and Kafka needs some work to re-align what we intended with the configurer pattern.