.Net: Change Sqlite connector to accept connection string instead of DbConnection

[roji]

• I believe that IVectorStore and IVectorStoreRecordCollection should have clear guarantees around thread-safety/concurrency, which should be clearly documented etc. For example, we shouldn't have one implementation/instance of IVectorStoreRecordCollection which is thread-safe, and another which isn't (in the way that SqliteVectorStoreRecordCollection is, by closing over SqliteConnection, which itself isn't threasd-safe).
• If we agree on the above, I believe the MEVD abstractions should be thread-safe; IVectorStore and IVectorStoreRecordCollection conceptually represent/reference database-side entities (the database itself, a collection within the database), and not e.g. a connection to the database (like DbConnection); so an instance doesn't represent something that's client-side stateful (again, like a connection). Also, in most databases, the client is thread-safe, representing simply a way to execute calls (e.g. via gRPC) on the database.
• The proposed implementation is very similar to the PostgreSQL one - a (pooled) connection is retrieved and opened for each operation, and then closed. Note that this means that Data Source=:memory: cannot be used, since the databases only lives while the connection is open, and disappears immediately when closed.
• Unlike the PostgreSQL implementation, there's no SqliteDataSource like there is NpgsqlDataSource (but I hope there will be at some point - see #30991); there's a DbDataSource abstraction in ADO.NET which we could theoretically accept, but that's not accepted usage, and in any case, we require a SqliteConnection (not DbConnection) in order to e.g. call LoadExtension(), and so would need to down-cast DbConnections coming out of DbDataSource in any case. As a result, I'm proposing that for now, the Sqlite connector simply accept a connection string, which is the natural/common way for ADO.NET-related things to work. In the future, when a SqliteDataSource is introduced, we can add support for that like we have for NpgsqlDataSource.
• I started out trying to preserve (but obsolete) the ability to accept SqliteConnection (to avoid the breaking change), but it turned out quite complicated, requiring lots of refactoring just for that, and a bit of risk of getting it wrong. Since this would be a temporary, two-month obsoletion only, and this is a SQLite-only break, I'm proposing to break this now rather than do all the effort and take on the risk for the two months we have. So I've obsoleted the relevant APIs with [Obsolete(error: true)], to have an informative error message for the user.

Closes #10454

/cc @westey-m @dmytrostruk @adamsitnik

[roji]

Note the change from transient to singleton lifecycle here - this aligns with other connectors.

[adamsitnik]

Please see my question, I would like to get a better understanding of the connection pooling first.

[adamsitnik]

Does SqliteConnection type implements it's own private pool of connections? So we don't actually open a new connection every time this method is being called?

[roji]

Yep, that's exactly right - that's the pattern that all .NET database drivers follow in general.

Static/private/implicit pools are (IMHO) generally a bad idea, which is why we introduced the DbDataSource abstraction - that's basically meant to be a factory for connections, and can explicitly represent a connection pool; so it allows users to manage pools explicitly (plus other benefits). Unfortunately, for now only Npgsql properly implements this (and I think maybe mysqlconnector).