.Net: [MEVD] Added GetService and Metadata for vector store abstractions

[dmytrostruk]

Motivation and Context

Related: #11013

This PR marks IVectorStoreRecordCollection.CollectionName property as obsolete in favor of Metadata classes and GetService method (the approach which is also used in MEAI).

GetService method is added to each vector store interface and each implementation is updated to return Metadata classes or underlying services used for breaking-glass scenarios. (Note: this is a breaking change for already existing implementations, since new GetService method should be implemented).

The changes allow to:

• Extend vector store related metadata by exposing not only CollectionName, but other properties like VectorStoreName, DatabaseName and any other potential properties in the future. These properties are going to be used in telemetry decorators, which will be implemented in separate PR.
• Get access to underlying services used by vector store implementations for breaking-glass scenarios (when functionality from abstraction is not enough to handle a specific use case).

@westey-m @roji

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 😄

[roji]

This isn't against your work or this PR at all, but I honestly am not sure why we need to expose an Azure AI Search via a GetService() API on our own abstraction... If the user needs a SearchClient (or any other connector-specific service), isn't it more reasonable for them to simply register that in DI themselves and get that directly, rather than getting it through our abstraction? In other words, it seems much more reasonable for the user to have a SearchClient in DI, have that picked up by the MEVD connector, and wherever they need the SearchClient, get that directly.

Again, I know that this is the MEAI approach and you're just aligning to it - so this isn't really about your work. Let me have a quick conversation about this offline to understand what I'm missing.

[dmytrostruk]

Sure thing. From my point of view, I guess there is no harm to expose underlying services via GetService if we already do that for metadata classes. I imagine when I work on some class, and I'm already injecting IVectorStoreRecordCollection, but for some reason I also need an access to underlying SDK, I can simply do collection.GetService() instead of introducing another dependency to that class, updating all the places where it's registered, unit tests and so on. It's also possible to mock GetService so it can return anything you want for your test scenarios.

As you said, in order to get an access directly, you will have to register that underlying service in DI on your side, but I don't think it should be required. In my app, I can simply do services.AddRedisVectorStore and with GetService I still can get an underlying service without registering it in DI, which sounds useful.

[roji]

If it's OK, let me think about this for another day or two, OK? I'm trying to figure out exactly in which scenarios this makes sense etc.

[dmytrostruk]

@roji Another option - if we are not sure about returning underlying services, we can't remove this logic for now and we can always add it later if we decide otherwise without breaking changes.