SQS inbound connector doesn't take polling delay into account on errors

[chillleader]

Describe the Bug

The SQS inbound connector doesn't take polling delay into account when the receiveMessage call returns an error.

This leads to eternal retries without delay every couple of ms when there is an error, e.g. when the queue doesn't exist or there is a network error.

Steps to Reproduce

1. Create an SQS inbound connector, specify a non-existing queue name but otherwise the config should be valid
2. Deploy the diagram
3. Observe never-ending polling requests without any delays (on the debug logging level)

Expected Behavior

1. Fail-fast check on connector startup whether the queue exists or not, the connector should not start if the queue doesn't exist
2. If an error happens during connector execution: add a retry policy, take the polling delay into account
3. Improve visibility: currently, errors during the SQS connector execution are logged on the debug level, which makes it difficult to spot errors.

Environment

• All connectors versions are affected where the SQS inbound connector is present

[chillleader]

This will partially fix the issue, full patch is targeted for the next release cycle: #3415

[sbuettner]

@chillleader Can we close this one?