Add IAsyncStartup and IAsyncStartupFilter to support async startup classes and filters

[analogrelay]

We should introduce a new set of interfaces: IAsyncStartup and IAsyncStartupFilter with the following API surface:

    public interface IAsyncStartup
    {
        IServiceProvider ConfigureServices(IServiceCollection services);

        Task ConfigureAsync(IApplicationBuilder app);
    }

    public interface IAsyncStartupFilter
    {
        Func<IApplicationBuilder, Task> Configure(Func<IApplicationBuilder, Task> next);
    }

Startup classes will now support a Task ConfigureAsync(IApplicationBuilder app) method, which is mutually exclusive with void Configure(IApplicationBuilder app). It shall be an error to have both methods on a startup class.

IAsyncStartup and IAsyncStartupFilter will be the primitives used by the entire Hosting pipeline. Adapters will exist in Hosting to allow the continued use of IStartup and IStartupFilter in the public API surface (to reduce breaking changes).

[analogrelay]

/cc @muratg

[Drawaes]

Please do! I could use this now

[davidfowl]

Don't change it, just add a new interface.

[analogrelay]

That's basically what I meant, updating to clarify.

[khellang]

Why does it have to be an error to have both? Couldn't you just have async be prioritized over sync? I.e. resolve IAsyncStartup first, then if It's not registered, resolve IStartup etc. StartupBase could implement both and have the async overload call the sync overload.

[davidfowl]

I think async should win over sync

[analogrelay]

We certainly could, it just seems like it's unnecessarily ambiguous. Wouldn't you have to explicitly register both to get in that scenario? All our helpers should be updated to register just the one (IAsyncStartup) with the necessary adaptors.

Either way, I'm fine, as long as the behavior is clear.

[davidfowl]

@anurse you may implement both on the same object.

[analogrelay]

I suppose. I just still think that's a pretty unclear situation, since you'll have code that we'll never call ourselves. Anyway, prioritizing async is the right approach if we're going to allow both.

[Tratcher]

@davidfowl The call stack for this doesn't make sense. Startup is instantiated and run from WebHostBuilder.Build(), not WebHost.StartAsync(), so Build() would have to become async for this.

[analogrelay]

Yeah. Making Build async is out of scope for 2.0 I think, it's way too late. What about reopening #1085 and moving IHostedService initialization to before Server initialization?

[Tratcher]

@muratg discussed this with @davidfowl offline, this should move to Backlog to revisit in 3.0.

[grahamehorner]

please try to be consistent with async naming conventions StartAsync() StopAsync() on Hosting IWebHost would suggest that interface naming should be IStartUpAsync and IStartupFilterAsync ? thoughts