Consider introducing ServiceBusSessionReceiverOptions

[JoshLove-msft]

Currently, we use ServiceBusReceiverOptions for both Session and regular receiver. This could be a problem if in the future options are introduced that should apply only to one or the other.
Right now the options would be identical (PrefetchCount and ReceiveMode).

Also, if we introduce the Accept session timeout option, as exists in Track 1, having a Session options bag would allow us the flexibility to include it in there rather than in the CreateSessionReceiverAsync method, though it still might make more sense to include as a named parameter in CreateSessionReceiverAsync.

On the other hand, the day where we need this might never come, and we would be introducing a new type that is identical to ServiceBusReceiverOptions for no reason.

Fixes #12092

[JoshLove-msft]

/cc @richardpark-msft

[SeanFeldman]

What does the PG say? Are there any immediate or near future plans to add/expand on the session receiver options?

[JoshLove-msft]

I'm unaware of any immediate or near future plans from the service, but this would protect us at very little cost. One piece of configuration that we may put there is the ability to configure the accept session timeout. As of Preview 2, this setting isn't exposed and we aren't planning on adding it for Preview 3. Having the options bag would give us a place to put it, and any other future options.

[JoshLove-msft]

There is the potential for there to be upcoming options that may apply only to non-session use case.

[SeanFeldman]

@JoshLove-msft may I suggest adding an indication that the issue was not closed as 'withdrawn' but rather implemented? This can be done either by leaving a comment such as

closed via d07dcc5

or by having PR description saying

closes/fixes #12092

And when PR is merged, the corresponding work issue will be automatically closed with a reference to the PR. Thank you 🙂

[JoshLove-msft]

Sorry about that. Thanks for adding the link @SeanFeldman!