Add support for auto-configuring SimpleMessageListenerContainer

[vpavic]

This commit introduces a new spring.jms.listener.container-type configuration property which can be used to auto-configure JMS listener support backend by SimpleMessageListenerContainer instead of DefaultMessageListenerContainer.

[snicoll]

Thanks for the suggestion but we don't really consider a promotion of SimpleJmsListenerContainer to that level. We invest in DefaultMessageListenerContainer for many years and I'd rather not confuse users by giving them a choice.

What's your use of SimpleJmsListenerContainer and why can't you use DefaultMessageListenerContainer.

[vpavic]

Semantics of SimpleMessageListenerContainer are quite different from polling-based approach that DefaultMessageListenerContainer are a better fit for some use cases. Your comment sounds like use of SimpleMessageListenerContainer is discouraged and I don't see that being the case looking at Message Listener Containers section of the Spring Framework reference docs that says this about SimpleMessageListenerContainer:

This message listener container is the simpler of the two standard flavors. It creates a fixed number of JMS sessions and consumers at startup, registers the listener by using the standard JMS MessageConsumer.setMessageListener() method, and leaves it up the JMS provider to perform listener callbacks. This variant does not allow for dynamic adaption to runtime demands or for participation in externally managed transactions. Compatibility-wise, it stays very close to the spirit of the standalone JMS specification, but is generally not compatible with Jakarta EE’s JMS restrictions.

My specific use case is that I'm using SQS and Amazon SQS Java Messaging Library provided by AWS. This JMS implementation doesn't support transactions, but provides custom acknowledge mode that better fits SQS, and internally has its own prefetching/polling mechanism that aligns usage of SQS API with JMS spec. From my experience SimpleMessageListenerContainer is a better fit here since I don't want another layer of polling (and associated set of threads) and dynamic concurrency.

I'd like to avoid copying boilerplate configuration from project to project and use configuration property based approach to opt into using SimpleMessageListenerContainer while also retaining the ability to configure other message listener aspects using properties.

[vpavic]

This override is here to preserve backwards compatibility (see #44466), as AbstractJmsListenerContainerFactoryConfigurer introduced in this PR reduces visibility to package private.