Consider enabling auto-startup for `DefaultStreamMessageListenerContainer`

[mp911de]

DefaultStreamMessageListenerContainer.isAutoStartup returns false. It would be neat to control the auto-startup feature, defaulting to true

[jxblum]

@mp911de - Why was the Spring Framework SmartLifecycle interface, isAutoStartup() method (Javadoc) overridden on the DefaultStreamMessageListenerContainer class to return false in the first place?

There must have been (you must have had) a reason to begin with when this class was first conceived??

By default, the Spring SmartLifecycle.isAutoStartup() interface method returns true, which means the Spring container would automatically tie the startup and (appropriate) stop (shutdown) of the SD Redis StreamMessageListenerContainer to the lifecycle of the Spring container, in the appropriate phase" if we must.

Minimally, it would be trivial to make the auto-start function of this StreamMessageListenerContainer configurable.

[jxblum]

Also worth mentioning, SD Redis's (SDR) regular RedisMessageListenerContainer class implements the Spring Framework SmartLifecycle interface (as well), but uses the default value (true) for the default isAutoStartup() interface method, as defined in the core framework:

default boolean isAutoStartup()

Returns true if this Lifecycle component should get started automatically by the container at the time that the containing [ApplicationContext](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/ApplicationContext.html) gets refreshed.

A value of false indicates that the component is intended to be started through an explicit [Lifecycle.start()](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/Lifecycle.html#start()) call instead, analogous to a plain [Lifecycle](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/Lifecycle.html) implementation.

The default implementation returns true.

[mp911de]

I am trying to remember why it was overridden. I suspect some implementation methods generation mishap. In any case, having this flag configurable and setting it to enabled by default makes sense.