Improve fluent API with builder pattern when registering Azure Service Bus message pump

[tomkerkhove]

Is your feature request related to a problem? Please describe.
Improve fluent API with builder pattern so that we control what the following methods are that can be called.

services.AddServiceBusQueueMessagePump(secretName, options => options.JobId = jobId)
            .WithServiceBusMessageHandler<OrdersAzureServiceBusMessageHandler, Order>();
services.WithAutoRestartServiceBusQueueMessagePumpOnRotatedCredentials(...);

This is to make it more clear and less verbose since every extension we have today is returning IServiceCollection.

This also helps new people to explore what the other options are for configuring the runtime.

Describe the solution you'd like
Return a IServiceBusMessagePumpBuilder which enforces you to call WithServiceBusMessageHandler, WithAutoRestartOnRotatedCredentials and/or ... after AddServiceBusQueueMessagePump

services.AddServiceBusQueueMessagePump(secretName, options => options.JobId = jobId)
+++     .WithAutoRestartOnRotatedCredentials(...)
        .WithServiceBusMessageHandler<OrdersAzureServiceBusMessageHandler, Order>();
--- services.WithServiceBusMessageHandler<OrdersAzureServiceBusMessageHandler, Order>(); <-- No longer possible on services directly
--- services.WithAutoRestartServiceBusQueueMessagePumpOnRotatedCredentials(...); <-- No longer possible on services directly

What I would not do, however, is have a Build method at the end.

Describe alternatives you've considered
Nothing specifically, but open to suggestions.

Additional context
Add any other context or screenshots about the feature request here.

[tomkerkhove]

Thoughts @fgheysels ?

[stijnmoreels]

Yes, was something I thought about too, but didn't go through with it because it's actually some kind of breaking change, but since we're almost on the next major version we can indeed thing about this.
It's an approach that's also more in line with how the other .NET services are registered.

[fgheysels]

What I would not do, however, is have a Build method at the end.

What exactly do you mean ? You'll need to have something that actually finishes the setup of your builder, and leads to building the messagepump ? Or do you mean that this should be hidden ?

[stijnmoreels]

What I would not do, however, is have a Build method at the end.

What exactly do you mean ? You'll need to have something that actually finishes the setup of your builder, and leads to building the messagepump ? Or do you mean that this should be hidden ?

The actual build up will be when internally the .BuildServiceProvider will be called. This fluent API is about registration, not creation.

[tomkerkhove]

@fgheysels Ideally I would just have to do this:

services.AddServiceBusQueueMessagePump(secretName, options => options.JobId = jobId)
        .WithAutoRestartOnRotatedCredentials(...)
        .WithServiceBusMessageHandler<OrdersAzureServiceBusMessageHandler, Order>();

Which doesn't require a Build at the end, but if it's required then that's fine - Although a better name should be used then.

However, it could lead to cases where people didn't call it, nothing is happening and they are confused. Docs could help with that, but that wouldn't be enough.

[stijnmoreels]

If we do this (separate services), singletons defined could be created more than once, though. Just a remark.

[tomkerkhove]

Isn't that something we can/should manage?

[stijnmoreels]

Isn't that something we can/should manage?

'Can' in 'We can circumvent that?'
'Should' as in 'We should circumvent that?'

[tomkerkhove]

I think we should be able to manage that, no?