Add "copy" method to AstraDBVectorStore

[hemidactylus]

This method returns a copy of the vector store with all properties unchanged except the caller information a few properties if passed, including the caller information (used for usage stats by Astra DB's Data API), replaced by the new supplied values.

This is needed by the implementation of Graph Vector Store as a Retriever delegating to the vector store class:

new_vstore = vstore.copy(component_name="another_component_name")

The method does instantiate a new AstraDBVectorStore with dummy values and SetupMode=OFF to avoid triggering any actual work, then proceeds to replace all "private" members of the new instance to make it an exact copy, save for the "component name" changed fields. This has required a similar logic to be coded into the AstraDBEnvironment/CollectionEnvironment as well.
(The alternative of making room in the constructor for such a path was deemed too consequence-bearing to be pursued.)

Edit: method renamed from with_component_name to copy and range of accepted parameters expanded, see discussion in the PR

[cbornet]

How about having a copy(**kwargs) method ?

def copy(**kwargs):
    return _AstraDBCollectionEnvironment(
            collection_name=kwargs.get("collection_name", self.collection_name),
            token=kwargs.get("token", self.token)
            api_endpoint=kwargs.get("api_endpoint", self.api_endpoint),
            keyspace=kwargs.get("keyspace", self.keyspace),
            environment=kwargs.get("environment", self.environment),
            ext_callers=kwargs.get("ext_callers", self.ext_callers),
            component_name=kwargs.get("component_name", self.component_name),
            setup_mode=kwargs.get("setup_mode", SetupMode.OFF),
            collection_embedding_api_key=kwargs.get("collection_embedding_api_key", self.collection_embedding_api_key),
        )

[hemidactylus]

The reason I did not generalize so much is that not many arguments (to the constructor) would lean correctly to this kind of "duplication with just some tweaks". For instance:

• we hardcode setupMode to be OFF since we want this "copy" to not do any side-effect and be instantaneous (this is the main obstacle)
• it would be strange, then, to expose the possibility of changing collection name since we don't offer a way to go through the usual create-collection flow. (For such operations, I suppose, we should only leave the "regular legitimate constructor" route)
• ditto for api endpoint, environment

In my opinion, perhaps the case could be made for this "copy" to support on-the-fly change of just token, ext_callers, collection_embedding_api_key and component_name, probably nothing else would make it "safe" for usage by the coder from the outside.

But then, calling it "copy" seems a stretch and it could remain as is (possibly generalized to these 4 params and aliased if ever the need arose).

At least that was my reasoning, I'm happy to discuss it further!

[cbornet]

I see. I would still lean on calling it copy() and limiting the args that can be changed.
If you call copy() without args, that's effectively a shallow copy.
The question is then how to signal to the user which args are allowed.
Maybe it can be in the signature with meaning None is take value from original and not set it to None ?
I originally proposed kwargs because it could distinguish between "not set" and "set to None" but maybe "set to None" is not needed/allowed.

[hemidactylus]

This is a valid point. I am renaming to copy right now, with a modicum of docstring to highlight the details of behaviour.
Also the eternal "unset VS None" issue in this case does not bite since I agree that passing explicit None has no purpose whatsoever (esp. considering there are idiomatic ways to suppress token and/or API Key that do not involve passing None. I mention them in the new docstring).

[cbornet]

Could also be copy(**kwargs)

[hemidactylus]

(same reasoning as above)

[hemidactylus]

I'm adapting this in line with above. ==> copy

[cbornet]

Why not passing the final values instead of moot directly ?

[hemidactylus]

My intent here was to ensure future readers understand the nature of this "trick", that the instantiation is misused so to speak - exploiting a path in the constructor where nothing happens.

The concern was that passing the real values (which however need to be supplied with more member-setting right thereafter) might mislead readers.

[hemidactylus]

exploiting a path in the constructor where nothing happens.
I am not very proud of this solution, to be honest. But it probably seems overkill to refactor everything else to make this little flow more straightforward.

[cbornet]

LGTM!