In complex setup, a message produced from a cluster that had queue interest from leafnodes (either hub or spoke) would sometimes not deliver a message if the interest was a leafnode that had the interest on behalf of a gateway.
In the setup described in the issue this PR fixes, "Cluster B" may have picked "Cluster C", but that cluster does not have local queue interest, only the leafnode interest from "Cluster B", and would pick a LEAF connection to this cluster, but then suppress the message since it came from "B" so "C" cannot send it back there.
But picking a queue sub for "B" in "C" would then prevent the message to be delivered to the gateway "D".
In complex setup, a message produced from a cluster that had queue interest from leafnodes (either hub or spoke) would sometimes not deliver a message if the interest was a leafnode that had the interest on behalf of a gateway.
In the setup described in the issue this PR fixes, "Cluster B" may have picked "Cluster C", but that cluster does not have local queue interest, only the leafnode interest from "Cluster B", and would pick a LEAF connection to this cluster, but then suppress the message since it came from "B" so "C" cannot send it back there.
But picking a queue sub for "B" in "C" would then prevent the message to be delivered to the gateway "D".
Resolves #6125
Signed-off-by: Ivan Kozlovic ivan@synadia.com