HostFactoryResolver - Increase default timeout and add env var option

[maryamariyan]

Customer Impact

When customer has debugger attached or when using tools like EF migration, host startup path using WebApplicationBuilder for hosting and WebApplicationFactory<T> for testing, may fail to build and throw an InvalidOperationException with the message “Unable to build IHost.”, because the default timeout is only 5 seconds.

We are proposing to use a higher timeout (5 minute) to be used so that when an application is taking longer to build, we could allow startup code to complete, and the host can start successfully. Check comment here for more detail.

Increasing the timeout should not have a negative impact on experience.

We also added an environment variable option called DOTNET_HOST_FACTORY_RESOLVER_DEFAULT_TIMEOUT_IN_SECONDS in case user needs to set their own custom timeout.

See issue: #60891

Testing

Check PR #61621

Risk

Very low.

Regression

No, new 6.0 feature/code flow for discovering a host

cherry pick of #61621

[ghost]

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	maryamariyan
Assignees:	-
Labels:	area-Extensions-Hosting
Milestone:	-

[safern]

We need packaging changes. See: 39ecea6#diff-c7518d66e82e24aa3bb3bcf33bfa8717242e02d446983237f6ae56602785fde6R12 for an example.

Make sure that the package is created locally when building all configurations leg.

[eerhardt]

We need packaging changes.

I'm not sure if it matters, but this package isn't a traditional library package.

1. It is a "source-only" package
2. It isn't shipping on nuget.org. It is only created for other teams (like EF) to consume.

Hopefully that doesn't change how we service this package, but I just wanted to call that out.

[safern]

Thanks, @eerhardt for calling that out.

I'm not sure how we build source packages, but I believe we still need the GeneratePackageOnBuild set to true in order for the servicing builds to generate the package. Just looked at the latest release/6.0 official build and it didn't produce this package at all.

I would still bump the servicing version even though it doesn't land on NuGet.org as that helps reason about versions even for internal consumption, i.e aspnet transport packages also get that patch version bumped.

[ericstj]

I would still bump the servicing version

Looks like this happens automatically for this package.

[ericstj]

Looks like this happens automatically for this package.

Or perhaps that's the default unless you specify ServicingVersion. In which case we should specify it. Aside: I wonder if we can enforce this in servicing so that folks don't accidentally miss it.

[safern]

Tests are definitely unrelated. I will open issues for them.