LIVE-4704: Allow sender workers to poll SQS queues for messages

[frankie297]

What does this change?

As part of the work to create an EC2-based sender worker we want the ability to allow our sender workers to poll multiple SQS queues for received messages, and to clean up these messages after processing.

This PR includes:

• Adding an async SQS client, so we can asynchronously process messages
• Adds a pollQueue function that will use the sqs client to call the receive messages function
• Adds a long polling wait time of 20 seconds, AWS say this helps with empty responses and false empty responses. It also helps reduce costs
• We then parse the received message and delete the message from the queue after the message has successfully processed
• in the event of no messages on the queue, it will poll for 20 seconds before completing.
• Removes the previously hard coded test notification

How to test

• When testing locally, this PR updates the script to include the new sqsEc2Url parameter, for the EC2 SQS queue arns.

I tested locally, adding a message manually onto a queue (the iOS sender) and triggering the sender worker. Scenarios tested were:

• Receiving and processing a message from the queue
• Polling an empty queue
• Polling a queue with multiple messages (in this scenario only one message was processed)
• Deleting messages from the queue

This PR sets up the ability to poll, and the configuration. In a following PR will be the functionality to actually poll the queues on some sort of loop.

With the help of @DavidLawes

[DavidLawes]

Given this is a step towards continuous polling and further development work, it looks good to me :)

[DavidLawes]

The wait time might be something we want to experiment with later on, there might be some tradeoff we'd be willing to make, eg make more api calls but more quickly get messages off the queue

[DavidLawes]

I think ReceiveMessageRequest can accept a getMaxNumberOfMessages, which would allow us to get more than 1 (up to 10) messages from the queue for each api call. This might be a setting we experiment with later, but probably not something we need to add now

[DavidLawes]

At the moment handleChunkTokens returns Unit and the method itself handles all failures resulting from processing. Without changing some of the internal logic of this method (used by both lambdas and ec2) we didn't think we could conditionally delete messages from the source queue and/or put onto a dlq.

We decided for now that, as long as the ec2 service has started correctly and has begun polling, we will delete any messages we receive.

We should check what happens if any of the messages fail to send (I thought we logged errors from handleChunkTokens and also triggered alerts)