ensure client functionality is aligned with docs usage

[tsmith023]

This PR fixes problems surrounding passing lists to value<> fields and is an artefact of the previous confusions surrounding how data types must be passed to Weaviate through the GraphQL and REST functionalities.

In the previous release, the hard requirement was added to the GraphQL filters when this was neither necessary nor required. This PR undoes a final aspect that was missed from the latest patch and is causing confusing errors upon usage due to the difference between the available library and the valid documentation.

A user reported the following problem in the community Slack:

Hi all, what is the correct way to use the new ContainsAll/Any operator in the python client when filtering ? I see there have been some patches in the last few days but I can’t seem to make it work. I’m currently building up a list of operands with my containsAll one looking like:

operands.append(
    {
        "operator": "ContainsAll",
        "valueText": [tag],
        "path": ["tags"],
    }
)

But this always gives me the error Cannot provide a list when constructing where filter for valueText with ['myTag'] , however from what I can see in the docs for containsAll/Any this is the recommended structure. Any help would be appreciated.

The problem is these conditions that I added originally when I thought it was a requirement that the argument value<> match the value when making a where filter. This is only true of batch.delete_objects and not of gql.filter so it is leading to bugs since the docs report that value<> is used with an array argument [] , e.g. "valueInt": [1] etc.

So it will no longer throw a client error when users say "valueText": [tag], only throwing an error if they say "valueTextArray": tag, since that is demonstrably incorrect whereas the first is only semantically incorrect (it still works with Weaviate despite having confusing wording).

[dirkkul]

ok, I'm confused now with what works and what doesn't?

Could you please write a few examples that describe exactly where the problem is?

[dirkkul]

to be sure that these are working in the future, can you please add some integration tests with all of these filters?

best would be a parametrized test that goes through each filter/type value type combination