deadletter poison message explicitly

[march425]

In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-release

Describe the feature

Dapr pubsub does not provide a way to deadletter a poison message explicitly. AFAIK, the only way to deadletter poison messages today is to let the retry policy be exhausted until the message lands in the DLQ. Obviously this consumes resources unnecessarily. Dealing with poison messages efficiently is an integral part of a scalable message consumer.

The current contract needs to be revisited. Currently there's no difference in behavior between SUCCESS and DROP. They both consider the message handled and it's removed from the Q.
Either make DROP dead-letter immediately or add a new response for DEADLETTER.

Release Note

RELEASE NOTE:

[artursouza]

I agree to make DROP move message to deadletter. Creating a new response type when SUCCESS and DROP have same behavior would be confusing IMO. So, for customers that don't want a message to be processed ever, SUCCESS is still there.

[artursouza]

As part of this work, adding E2E test is important to make sure this change in behavior remains in future versions.

[Taction]

/assign