feat: add AddClickHouseClient extension method for DI registration

[nandor23]

Summary

Provides a standard .NET pattern for registering IClickHouseClient as a singleton in the dependency injection container, as mentioned in #225.

Usage:

// Registration in Program.cs
services.AddClickHouseClient("connection-string");

// Injection
public class MyService
{
    public MyService(IClickHouseClient client)
    {
        // Same singleton instance injected everywhere
    }
}

Checklist

Delete items not relevant to your PR:

• Unit and integration tests covering the common scenarios were added
• A human-readable description of the changes was provided to include in CHANGELOG

---

Note

Low Risk
Small additive change limited to DI wiring plus unit tests; main risk is incorrect lifetime/validation behavior, which is covered by tests.

Overview
Adds a DI registration entrypoint via IServiceCollection.AddClickHouseClient(connectionString), which validates the connection string and registers IClickHouseClient as a singleton backed by ClickHouseClient.

Introduces unit tests ensuring the service resolves as a singleton and that null/whitespace connection strings throw ArgumentNullException.

^{Written by Cursor Bugbot for commit 8c3d031. This will update automatically on new commits. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

[cursor]

DI extension in wrong namespace, duplicating existing class

High Severity

The AddClickHouseClient extension method is placed in namespace ClickHouse.Driver, but this project already has a ClickHouseServiceCollectionExtensions class in Microsoft.Extensions.DependencyInjection (in DependencyInjection/ClickHouseServiceCollectionExtensions.cs). The standard .NET pattern — and the existing project convention — is to put DI extensions in Microsoft.Extensions.DependencyInjection so they're auto-discoverable without extra using directives. This creates a confusing duplicate class name and makes AddClickHouseClient invisible to users unless they add using ClickHouse.Driver.

 

[nandor23]

The existing ClickHouseServiceCollectionExtensions seems unnecessarily complex. The library documentation states that ClickHouseClient is "thread-safe" and "designed for singleton use", suggesting it handles resource management internally. It also only works with .NET7 and above.

Given this design, DI extensions shouldn't need custom HttpClient management, factory lambdas, or warning suppressions. A simple registration approach should suffice

[cursor]

Wrong exception type for empty/whitespace connection strings

Low Severity

The validation uses string.IsNullOrWhiteSpace which catches null, empty, and whitespace-only strings, but always throws ArgumentNullException. When connectionString is "" or " " (not null), throwing ArgumentNullException is semantically incorrect — ArgumentException is the appropriate type for non-null invalid arguments.