failover redelivery to alternative consumers with pending transaction causes rollback *and* dlq processing

failover isolates the application client from transport failures. For a single consumer, if there is a pending transaction and an ack is lost the transaction can still commit after failover if the messages is redispatched. If it is not redispatched, then the transaction will rollback.
With multiple consumers it is possible that an alternative consumer will get redelivery. If the alternative consumer is on a different connection the duplicate dispatch (tracked by a connection) is not identified, redelivery ensues and the pending transaction rolls back.
If the consumer is on the same connection, the redelivery is treated as a duplicate, the message gets a poison ack and the pending transaction rolls back. This is a double whammy and results in a delivery to the DLQ in error.

The redelivery should be routed to the alternative consumer as if it were on a different connection so that the message can be consumed.
We should DLQ only when the redispatch is not pending on any consumer.