EndpointBuilder.ApplicationServices should use init instead of set

[halter73]

Background and Motivation

When doing more work with EndpointBuilder as part of #43543, I noticed that it was odd and unnecessary that ApplicationServices could be modified after construction. Using init doesn't completely prevent this, but it makes it clear it's unintended.

I also think that IEndpointMetadataProvider and IEndpointMetadataProvider belong in Http.Abstractions instead of Http.Extensions. It doesn't have any big dependency, and we already have all our other endpoint metadata related stuff there like EndpointBuilder itself.

Proposed API

namespace Microsoft.AspNetCore.Builder;
 
public abstract class EndpointBuilder
{
-    public IServiceProvider ApplicationServices { get; set; } = EmptyServiceProvider.Instance;
+    public IServiceProvider ApplicationServices { get; init; } = EmptyServiceProvider.Instance;
}

- Microsoft.AspNetCore.Http.Extensions.dll
+ Microsoft.AspNetCore.Http.Abstractions.dll

namespace Microsoft.AspNetCore.Builder;

public interface IEndpointMetadataProvider
{
     static abstract void PopulateMetadata(MethodInfo method, EndpointBuilder builder);
}

public interface IEndpointParameterMetadataProvider
{
     static abstract void PopulateMetadata(ParameterInfo parameter, EndpointBuilder builder);
}

Usage Examples

var builder = new RouteEndpointBuilder(requestDelegate, updatedRoutePattern, route.Order)
{
    DisplayName = action.DisplayName,
    ApplicationServices = _serviceProvider,
};

Alternative Designs

Leave it as set. Leave the providers in Http.Extensions.dll.

Risks

I think it's riskier to leave it as set. It's new API, and we could always remove the init-onlyness in a later release. I don't think it's a huge problem either way though.

If someone wanted to enlighten an existing EndpointBuilder they didn't construct, the C# language will now try to stop them from modifying it. This might be annoying, but changing this value after construction could lead to some weird hard-to-diagnose bugs.

I cannot think of any justification for not moving the providers to Http.Abstractions.dll.

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

This was approved over email.

@BrennanConroy points out "The set vs init part was likely an oversight during the API review. I don’t see any references in the PR/issue about why it was made settable, and no one is using the setter today." And that "the dll move also makes sense, those were the only interfaces in that assembly, which is probably a sign that this is a good move.