AWS SQS/SNS Wrong queue access policy (broken in last version (1.5.0))

[mhozhda-agiliway]

Expected Behavior

When some service is subscribed to many topics it's queue should have an access policy than allows all subscribed topics to publish events to the queue.

Actual Behavior

Currently the generated queue access policy has a condition that only allows one of the topics to publish events to it.
Tested that it is not always the same topic (I assume the last subscribed topic rewrites policy and restricts access to itself only)

Generated access policy example:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:region:XXXXXXXXX:your-service-name",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:region:XXXXXXXXX:lasttopicname"
}
}
}
]
}

In the previous version of dapr 'Condition' is not specified at all.

Seems to be broken with this commit:
e9deaf3
restrictQueuePublishPolicyToOnlySNS() method should add new sources to condition but not override existing

Steps to Reproduce the Problem

Create a test app that subscribes to few (>1) topics. Run the app with AWS SQS/SNS component configured for pubsub.
Check that instead of allowing all subscribed topics to publish to created queue it only allows it to one of them
in generated queue access policy.

Release Note

RELEASE NOTE:
Fixed bug with SQS/SNS wrong queue access policy

[mhozhda-agiliway]

@amimimor Sorry for tagging you directly, but probably you can implement a quick fix for it

[yaron2]

@amimimor please comment here with /assign.

[amimimor]

@yaron2 we need to re-open this issue as I found and fixed another issue related to the fix (localstack testing appear to be inadequate in terms of resource access policies)