feat: Add dependency injection support in a separate hosting package

[kinyoklion]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Describe the solution you've provided

Adds LaunchDarkly.OpenFeature.ServerProvider.Hosting, a new package containing the OpenFeature dependency injection / hosting registration:

services.AddOpenFeature(openFeature => openFeature
    .AddLaunchDarklyProvider(options =>
    {
        options.SdkKey = "my-sdk-key";
        options.ConfigureSdk = config => config.StartWaitTime(TimeSpan.FromSeconds(10));
    }));

Overloads exist for the default provider and for a domain-bound provider, each with and without an inline Action<LaunchDarklyProviderOptions> (so options can also be bound from configuration). LaunchDarklyProviderOptions exposes SdkKey plus ConfigureSdk, a hook onto ConfigurationBuilder, rather than re-declaring the SDK's configuration surface.

The registration is in a separate package so that consumers of LaunchDarkly.OpenFeature.ServerProvider who do not use DI gain no new dependencies. dotnet pack confirms the provider package's dependency groups are unchanged (still only LaunchDarkly.ServerSdk and OpenFeature), and Microsoft.Extensions.* arrives only transitively through OpenFeature.Hosting in the new package.

Two behaviors worth noting for review:

• OpenFeature.Hosting registers providers as transient, and each LaunchDarkly provider constructs an LdClient with its own connection to LaunchDarkly. The internal ProviderRegistry therefore holds one provider — and thus one client — per domain, so resolving FeatureProvider more than once cannot open additional connections. The upstream flagd and OFREP providers construct a provider per resolution instead; that is cheap for them, and not for us.
• The ILdClient used by each provider is registered too (keyed by domain for domain-bound providers), so migration flags and track events remain reachable. It is shut down along with the provider when the host stops.

The new package is versioned and released in lockstep with the provider: the version marker is in release-please-config.json extra-files, and the release build and publish actions build and pack both projects.

Describe alternatives you've considered

• Adding the extensions directly to LaunchDarkly.OpenFeature.ServerProvider, as the upstream flagd and OFREP providers do. Rejected because it puts OpenFeature.Hosting and the Microsoft.Extensions.* closure in every consumer's dependency graph.
• Marking the DI dependencies PrivateAssets="all" to keep them out of the nuspec. Rejected: they are needed at runtime, so this only moves the failure to the consumer.
• Independent versioning for the new package. Lockstep keeps the provider dependency exact and the release process unchanged; happy to switch if you'd rather version it separately.
• Naming it .DependencyInjection after the deprecated upstream package. .Hosting matches where the functionality now lives upstream.

Additional context

OpenFeature.Hosting is still described upstream as experimental, and since 2.14.0 the DI integration uses an isolated Api instance rather than Api.Instance — so a provider registered through DI is not visible to code evaluating flags through the global singleton. This is documented in the README; the minimum OpenFeature.Hosting version is 2.14.0 so that behavior is consistent.

How to test: dotnet test (77 tests: 72 existing, 5 new). To check dependency isolation, dotnet pack both projects and inspect the .nuspec dependency groups.

Link to Devin session: https://app.devin.ai/sessions/e52b5c9dfeec452cbfe1e8b8b8506c34
Requested by: @kinyoklion

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review