EndpointBuilder.ServiceProvider should be non-nullabe and renamed to ApplicationServices

[halter73]

Background and Motivation

We missed this when renaming Services to ApplicationServices on a few other types in #41900 (comment).

Proposed API

namespace Microsoft.AspNetCore.Builder;

public abstract class EndpointBuilder
{
-    public IServiceProvider? ServiceProvider { get; set; }
+    public IServiceProvider ApplicationServices { get; set; }
}

Usage Examples

var serviceProvider = routeEndpointBuilder.ApplicationServices;
var hostEnvironment = serviceProvider.GetService<IHostEnvironment>();
var serviceProviderIsService = serviceProvider.GetService<IServiceProviderIsService>();

Alternative Designs

Keep ApplicationServices nullable. OpenApiRouteHandlerBuilderExtensions currently has different behavior if the IServiceProvider is null or not. If it's null it doesn't add any metadata to the endpoint.

aspnetcore/src/OpenApi/src/OpenApiRouteHandlerBuilderExtensions.cs

Lines 70 to 78 in f5ee9e3

	var serviceProvider = routeEndpointBuilder.ServiceProvider;
	if (methodInfo == null || serviceProvider == null)
	{
	return null;
	}
	var hostEnvironment = serviceProvider.GetService<IHostEnvironment>();
	var serviceProviderIsService = serviceProvider.GetService<IServiceProviderIsService>();

Is this what we want for WithOpenApi? Could it be valid to change behavior given a "null" ServiceProvider for other things adding endpoint metadata? What about route handler filters with RouteHandlerContext.ApplicationServices? Technically, we're only hiding information by making these non-nullable. Maybe this is best to hide this information so people don't short circuit for a null service provider. I'm not sure. What do we think @captainsafia @DamianEdwards @davidfowl?

We could also keep the ServiceProvider name even though we've avoided it in other APIs. It does align with IEndpointRouteBuilder.ServiceProvider that first shipped in 3.0. I do like the increased clarity of ApplicationServices though, and we seem to use that in more places.

Risks

This hasn't shipped in a major release, so the risk is not doing this before we are unable to make breaking changes.

[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.

[halter73]

API review notes from @captainsafia:

• [this proposal] is a sensible change that reflects our efforts to make use of IServiceProvider​ in contexts more consistent.