[Mvc] Support IAsyncDisposable for controllers and pages

[javiercn]

[Fixes #13150]

*Adds async versions of Release to the relevant interfaces in different
factories and activators.

• The new methods offer a default interface implementation that will
  delegate to the syncrhonous version and just call dispose.
• Our implementations will override the default implementation and handle
  disposing IAsyncDisposable implementations.
• Our implementations will favor IAsyncDisposable over IDisposable when
  both interfaces are implemented.
• Extenders will have to override the new methods included to support
  IAsyncDisposable instances.

The general pattern is that there is a new method on the relevant interfaces that offers a default implementation that delegates to the sync version in the interface. The idea is that extenders will have to do work to support IAsyncDisposable too, but this way we avoid having a breaking change and libraries can add support at their own pace by overriding the default implementation.

We should consider marking the sync versions on the interface as [Obsolete] and point out to the new async versions.

Alternatively we could consider doing a breaking change here since it's very early in the release and we have time to advertise it.

The goal is to minimize the problems due to incompatible libraries for people updating to 6.0.

[pranavkm]

This looks greats. Are you planning to update this for view components:

• https://github.com/dotnet/aspnetcore/blob/master/src/Mvc/Mvc.ViewFeatures/src/ViewComponents/IViewComponentFactory.cs
• https://github.com/dotnet/aspnetcore/blob/master/src/Mvc/Mvc.ViewFeatures/src/ViewComponents/IViewComponentActivator.cs

It might also be helpful to throw if an IView instance implements IAsyncDisposable rather than silently no-op. It's invoked in sync code-paths and supporting IAsyncDisposable is far too hard there. (e.g. https://github.com/dotnet/aspnetcore/blob/master/src/Mvc/Mvc.ViewFeatures/src/TemplateRenderer.cs#L138)

[javiercn]

@pranavkm those are great points.

I was mainly testing the waters to root out any big blockers. The part that I'm more concerned about is the extensibility, but I think the approach I followed offers a reasonable trade-off.

I think we should consider marking the existing sync releaser members as obsolete to hint authors to implement the async capable versions.

[javiercn]

I refactored this code because it wasn't consistent depending on whether the path was synchronous or async or whether the values were being logged.

[pranavkm]

new API :|

[ghost]

Hi @pranavkm. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[javiercn]

@pranavkm It's life 😃

I've added it to the API review next week

[ghost]

Hi @javiercn. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[pranavkm]

Obsolete and never delete.