MessageSender abstraction is broken for Path when Send-Via is used

Actual Behavior

MessageSender supports Send-Via feature. Send-Via is using a transfer queue to route message to their final destination when using transactional processing. The abstraction is represented by a public overload of MessageSender that takes in two paths

1. entitytPath
2. viaEntityPath https://github.com/Azure/azure-service-bus-dotnet/blob/e278f87b0b3aa563ab055918e988baec9ec155a3/src/Microsoft.Azure.ServiceBus/Core/MessageSender.cs#L127-L135

The abstraction has been copied from the old client and works, but it’s broken when Path and TransferDestinationPath are queried back. That’s because all public overloads are invoking an internal overload, swapping the two paths: https://github.com/Azure/azure-service-bus-dotnet/blob/e278f87b0b3aa563ab055918e988baec9ec155a3/src/Microsoft.Azure.ServiceBus/Core/MessageSender.cs#L132

where internal overload is https://github.com/Azure/azure-service-bus-dotnet/blob/e278f87b0b3aa563ab055918e988baec9ec155a3/src/Microsoft.Azure.ServiceBus/Core/MessageSender.cs#L137-L144

assigning viaEntityPath to this.Path and entityPath to this.TransferDestinationPath. Which is inverted.

Expected Behavior

Path and Send-Via/TransferDestinationPath after MessageSender constructor is invoked should be identical to the values passed in.

Repro

LinqPad repro script attached.

var sender1 = new MessageSender(connection, "path");
sender1.Path.Dump("Should be 'path'");
Assert.IsNull(sender1.TransferDestinationPath); // green

var sender2 = new MessageSender(connection, "path", "intermediate");
Assert.AreEqual("path", sender2.Path); // red, equals to "intermediate"
Assert.AreEqual("intermediate", sender2.TransferDestinationPath); // red, equals to "path"

Recommendations

The fix should be released as a major version for the following reasons:

1. This is a breaking change. While a fix will restore the correct behaviour, it will affect any existing solution relying on the incorrect implementation.
2. Anyone implementing a workaround will be broken if they update to a patch/minor.

[nemakam]

Yes

[SeanFeldman]

Needs to be a minor with the change made in PR. https://github.com/Azure/azure-sdk-for-net/pull/6941#issuecomment-512110678