UseSolutionRelativeContentRoot overloads to support slnx discovery

[slang25]

Background and Motivation

From @kimsey0 in issue #61304

WebApplicationFactory tries setting the content root based on a number of sources (a builder setting, MvcTestingAppManifest.json, and the assembly metadata) before falling back to setting a solution-relative content root. This looks specifically for a .sln file, which means any test that relies on it breaks when migrating to the new SLNX solution format.

A proposed implementation can be found here: #61305

Proposed API

namespace Microsoft.AspNetCore.TestHost;

public static class WebHostBuilderExtensions
{
-    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath, string solutionName = "*.sln");
-    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath, string applicationBasePath, string solutionName = "*.sln");
+    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath);
+    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath, string solutionName);
+    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath, string applicationBasePath, string solutionName);
+    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath, string applicationBasePath, System.ReadOnlySpan<string> solutionNames = default(System.ReadOnlySpan<string>));
}

Usage Examples

before:

.UseSolutionRelativeContentRoot(Path.Combine("test", "WebSites", applicationName), "*.slnx")

after:

.UseSolutionRelativeContentRoot(Path.Combine("test", "WebSites", applicationName))

Alternative Designs

The solutionNames overload may be more appropriately take a IReadOnlyCollection<string> given that this api is called on a builder that is typical a one-time setup, so performance isn't particularly critical.

namespace Microsoft.AspNetCore.TestHost;

public static class WebHostBuilderExtensions
{
+    public static Microsoft.AspNetCore.Hosting.IWebHostBuilder UseSolutionRelativeContentRoot(this Microsoft.AspNetCore.Hosting.IWebHostBuilder builder, string solutionRelativePath, string applicationBasePath, System.Collections.Generic.IReadOnlyCollection<string> solutionNames = default(System.Collections.Generic.IReadOnlyCollection<string>));
}

Risks

While these changes should be binary and source compatible, we should double-check this.

[dotnet-policy-service]

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:

• We were unable to come up with existing code that this breaks, and we're okay with the ReadOnlySpan<string> with a default value.
• We made mistakes earlier with these overloads, but we don't think we're making it worse.

API Approved!

[halter73]

Completed by #61305