Ensuring "Path" returns the right destination in the case of via-sender

[nemakam]

Fixing #6031
In the case of Via-Sender defined by
viaSender = new MessageSender(connection, "path", "via"),

Assert.Equal("path", viaSender.Path);
Assert.Equal("path", viaSender.TransferDestinationPath);
Assert.Equal("via", viaSender.ViaEntityPath);

EDIT
Alternatively, to keep things from breaking and causing further confusion, keeping Path as-is and updating the xmldoc.

1. Path will now point to wherever the amqp-link is created to.
2. viaEntityPath will point to via entity.
3. TransferDestinationPath will point to the final destination of the message

[SeanFeldman]

With this change, when send-via is used, TransferDestinationPath is the real "path" and Path with SendViaPath are the same. Not sure this is less confusing. Personally, I find that confusing enough to warrant a change in a new major.

This would need to be released as a minor given a new property news added.

[nemakam]

@SeanFeldman, yes, this will be a new minor. Will take care of that during release time.
But regarding the output of Path, it becomes confusing either way. I ran by this scenario with multiple teammates of mine, and had mixed opinions on what the real value of Path should be. Is it the entity where the message is being sent to (i.e., the target of the link) or the actual message itself? Lets say there was another feature where you could just specify the real desitnation of the message within the message.To field and just use the amqp-link to send it to a temporary routing path. How does it look like then? Same AMQP link can be used to send to multiple entities. You cannot change Path based on different destinations. And, also, in the case of send-via, its best if users understand that the message is in fact being sent to the "via" entity right now and lazily being forwarded to "destinationEntity". Having the Path variable point to "via" does make sense in that way.
The cherry on top of it is that in the older client, people had the same discussion and decided to stick to Path being "via", and if the new client has a different behavior, that may break users unknowingly who are shifting from old client to new client.
In short, any value of Path would be confusing. Hence the new variable called ViaEntity and TransferDestination which should keep things clear.

[SeanFeldman]

The cherry on top predates my participation 😉
Would be good to see doco PRs linked to this issues/PR to ensure it's documented when minor is going out.
/cc @jfggdl