Add IGNORE QueueNotFoundStrategy Option for SQS

[OmarTareefy]

Type: Feature

Is your feature request related to a problem? Please describe.
Yes, currently in SqsMessageListenerContainerFactory there are two strategies to consider when a queue is not found, either CREATE or FAIL. In our business use case the CREATE will not be the best for us because we create the AWS queue with certain configurations and permissions and also we can't give the container running the application a create-queue permissions, in the other hand the FAIL strategy will not be good for us because in some cases the queue might not be created for that specific deployment and we would want the application to just start even if the queue is not there.

Describe the solution you'd like
It will be great if a new strategy is created called DO_NOTHING in QueueNotFoundStrategy enum where spring just ignores initializing the SqsMessageListenerContainerFactory for that SqsListener because the queue doesn't exist and the application start without issues.

Describe alternatives you've considered
I tagged my SQSConfig @configuration class with @ConditionalOnExpression(property == true) (this will be true by default) and created a spring bootstrap configuration class that pings the related queue using getQueueUrl and if that throws an exception (which means the queue is not there or the application doesn't have permissions) I set that property to false so that the SQSConfig @configuration class is turned off,

Another solution we considered is to set the autoStartup to false in the defaultSqsListenerContainerFactory and then at some point in the app startup, we get all of the containers from MessageListenerContainerRegistry and start them one by one, if the starting fails (because the queue is not created) we simply log an error and the app continues.

Please let me know if there is a better workaround or if there is a better solution for the issue I am facing that I am not aware of,
Thank you!

[tomazfernandes]

Hey @OmarTareefy, your workarounds sound reasonable.

Do they work well for you?

I think the main challenge for implementing this in the framework would be figuring out how to graciously handle the error thrown by the QueueAttributesResolver and interrupting container startup, but it should be doable.

PRs are welcome!