.Net: Adds support for providing own sql connection to the vector store connector

[MarvinPogoda]

Motivation and Context

A connection string tends to carry secrets as plain text, which easily leak into logs, telemetry, or configuration dumps.

Description

Providing a Func avoids passing secrets around entirely and allows credentials to be resolved securely at connection-creation time.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[MarvinPogoda]

@microsoft-github-policy-service agree

[roji]

@MarvinPogoda first, SqlClient provides multiple ways to connect to SQL Server without specifying the password in the connection string (SSPI, Active Directory auth, Entra ID...). These are indeed recommended as alternatives that remove the password entirely from your application.

If you're concerned about the connection string leaking, the above are the right techniques to prevent that; I'm not sure how accepting a SqlConnection provider quite achieves that. If the provided given by the user simply returns a SqlConnection constructed with a connection string, than this has achieved very little - the application still uses connection strings with passwords, and has only moved around the construction of the SqlConnection. On the other hand, if e.g. Entra ID is in use, then your proposed SqlConnection provider hasn't actually achieved anything, since the application was already secure. So how exactly do you see this as improving security?

I do agree that it makes sense to have a concept of a "connection factory" in SqlClient, which is responsible for all the details of constructing an authentication and closes over all the possible configuration. That's the idea behind the ADO.NET DbDataSource abstraction - see dotnet/SqlClient#2119 for the issue tracking this on the SqlClient side. With the PostgreSQL provider, for example, instead of passing in a connection string one can pass in an NpgsqlDataSource, which is conceptually similar to your Func - but is a first-class concept of the database driver itself. Once SqlClient implements SqlDataSource (the issue above), I agree that we should absolutely accept it here, but I'd rather not introduce a separate Func in the meantime as proposed.