fix Sqs fifo message group invisibility after triggering move to dlq

[baermat]

Motivation

Users raised the issue that fifo queues become unusable after messages were moved to a DLQ.
After a fifo queue's message's receive count exceeds the maximum and is moved to a DLQ, its message group remains invisible. This PR addresses this issue.
fixes #10107

Changes

• add method to allow the provider to call the missing visibility changes to the message group after moving the message

I am not happy with how this change is implemented, but I am unsure what the best way is.
The root cause is that we simply never addressed the message group visibility when a dlq move is triggered, so obviously we need to address that. There are two main ways to do this that I see:

• Provider calls the necessary code in the "move to dlq" block directly. That's what's happening now
  • Right now it contains an ugly isinstance(queue,FifoQueue) check, and the provider shouldn't care what kind of message it handles, the point of the different classes is to abstract that away.
  • We could also leave the current method as is and simply call queue._on_remove_message, to get rid of the Fifo check. But this method seems to actually be "queue._on_delete_message" from a program-logic point of view and is expected to be called during deletion. Moving a message to a dlq is very similar, but not quite the same, and this approach would result in e.g. a re-heapifying for a standard queue every time (that's the reason why this solution was discarded).
• Since moving the message to a dlq is a put operation, we could do a "if dlq move, unlock source queue message group" during the put to the dlq. This options also has the advantage that we can add this message group visibility related change to the place in the code where the other checks of this kind are. However we would need the source queue object for that:
  • We could pass the source queue object on the put operation as optional parameter. This means changing the signature of put for standard_queues too though, as well as passing it all the way down from the provider, and that doesn't seem that clean either.
  • We already pass the DeadLetterQueueSourceArn with the message, and could get the queue from said arn. This way, we would have the change exactly where it belongs (in my opinion) without touching other code from a program-logic point of view. However, the queues are not context aware, and we would need that to access the proper queue from the store. This comes with some medium sized refactoring and is therefore quite the architectural change, which was the reason why this was discarded.
    Sorry for the wall of text, if something is unclear please ask ahead. The reason for it is that message group visibility has been quite the back and forth with patching so far, so I'd like to make extra sure that we do this the right way.

[github-actions]

LocalStack Community integration with Pro

    2 files      2 suites   1h 39m 56s ⏱️
2 981 tests 2 676 ✅ 305 💤 0 ❌
2 983 runs  2 676 ✅ 307 💤 0 ❌

Results for commit 2c06c4b.

[thrau]

LGTM! nice catch 👌

[thrau]

i really regret not designing this in a way that we can easily do DLQ processing in the SQS abstraction, and have to do this on API level. well 🤷