When re-using SendOptions delayed delivery settings are discarded

[dbelcham]

It's not clear that SendOptions cannot be re-used, and to me it seems that there is disagreement on the topic since we fixed a bug ( #4613 ) that allows to re-use SendOptions in some scenarios.

@ramonsmits discovered that the following scenario fails:

var o = new SendOptions();
o.DelayDeliveryWith(TimeSpan.FromSeconds(10));
o.SetDestination("Samples.SqlServer.SimpleReceiver");

await endpointInstance.Send(new MyMessage(), o).ConfigureAwait(false);
await endpointInstance.Send(new MyMessage(), o).ConfigureAwait(false);
await endpointInstance.Send(new MyMessage(), o).ConfigureAwait(false);

Only the first send is delayed, subsequent sent messages are sent immediately ignoring the DelayDeliveryWith configuration. What happens is that we're silently removing the delivery constraint changing the SendOptions instance and at the same time allowing the user to re-use it.

[dbelcham]

This should be considered for the next maintenance release

[timbussmann]

I had a quick look at the other extensions and while some add objects to the context as well (which are vulnerable to leaking modifications because we only copy the reference, not the object itself), there are no other usages which change the state of these objects.

The only notable, potential issue is the routing API which does not guarantee cleanup, e.g. see this sample:

var sendOptions = new SendOptions();
sendOptions.SetDestination("test");
sendOptions.RouteToThisEndpoint(); // overrides the SetDestination setting
sendOptions.GetDestination(); // would still return "test"