.Net: [MEVD] Consider returning a simple list from IVectorStore.ListCollectionNamesAsync instead of IAsyncEnumerable

[roji]

We're considering doing the same thing with the database-generated IDs returned by IVectorStoreRecordCollection.UpdateBatchAsync (issue): working with IAsyncEnumerable is more difficult, and it's very unlikely that the streaming aspect is important here (or even supported by any actual connector).

[westey-m]

Here is a comparison of what the different DBs support today:

Database	Filtering Supported	Advertised as Lightweight Collections	CollectionsListingResponseType	MaxNumberOfCollections
AzureAISearch	N	N	Streaming AsyncPageable	3 000
MongoDB Atlas	Y	N	Streaming IAsyncCursor	100 000
Cosmos MongoDB Vcore	Y	N	Streaming IAsyncCursor	1 000
Cosmos NoSQL	Y	N	Streaming FeedIterator	499
Chroma	Limit/Offset	N	Http Response, so streamable	Not Documented
Milvus	Differs by SDK	N	Non Streaming List via GPRC / Http Response	65 536
Pinecone	N	N	Non Streaming List over GRPC	No limit?
Postgres	Y	N	Streaming NpgsqlDataReader	No limit
Qdrant	N	N	Non Streaming list over GRPC	No limit
Redis	N	N	Non Streaming list	Not Documented
Sqlite	Y	N	Streaming SqliteDataReader	Theoretical limit of 4 294 967 294
SqlServer	Y	N	Streaming SqlDataReader	Theoretical limit of 2 147 483 647 for all objects
Weaviate	N	N	Http Response, so streamable	Default: 1000, can be changed

Some DBs certainly support very large numbers of collections. Some also support it, combined with streaming retrieval methods.

Based on this, I think it makes sense to continue supporting IAsyncEnumerable. For those DBs that support streaming, it would certainly be preferable to locking up an application for a long time, while internally streaming the results and packaging them into a collection. Having an IAsyncEnumerable signals to users that many results may be there and getting all results may take time.

CC @roji @dmytrostruk @adamsitnik