Consider adding `autostart` property to `SqsOptions.Listener`

[akefirad]

Type: Feature

Is your feature request related to a problem? Please describe.
There are cases in which we might wanna have SQS integration (e.g. publishing messages) but disable SQS listeners. But currently there's no easy way to do this via configuration properties.

Describe the solution you'd like
Add a boolean flag to SqsProperties.Listener class; autostart or autoStartup (if you wanna be consistent with the property in SqsContainerOptions class).

Describe alternatives you've considered
Disabling the whole SQS integration (using spring.cloud.aws.sqs.enabled) but it doesn't support this exact use case.

Additional context
N/A

Happy to send the PR if needed.

[tomazfernandes]

Hi @akefirad, sounds good, looking forward to the PR.

[maciejwalkowiak]

I may be missing something, but couldn't you mark listener beans as @ConditionalOnProperty("listeners.enabled") and just not create these beans at all when they are not needed?

[akefirad]

Sure, that could work. But it's not as flexible as the boolean auto-start flag. Also seems a bit cleaner to me. No strong opinion. LMK.

[tomazfernandes]

I think the specific use-case this property would cover is when you want to have the containers but don't want them to start automatically, probably so you can start them up manually in a second moment through the MessageListenerContainerRegistry.

Overall I think it makes sense, since currently users would need to declare a Factory bean to have this behavior set to all containers.

For the specific use-case you brought @akefirad, I agree with @maciejwalkowiak that having them conditional on a property could also make sense since it'd prevent the beans from being instantiated at all, though the autoStartup property solution could make it simpler to manage than enforcing a condition pattern for all the listeners just for that.

Summing it up, if you want to contribute a PR with the autoStartup go ahead @akefirad, it'll be welcome.