No longer able to parse IN filter expressions against nested properties of dynamic objects

[atomaras]

We use OData filters in our web apis to power queries against a CosmosDB database.
We have built a custom parser that translates the OData syntax (AST) to CosmosDB SQL syntax.
This is how we do it:

OData .NET v7.18 broke my unit tests and I believe this PR might have something to do with it.
Our main entity defines a dynamic complex type property called metadata (open type, essentially just a dictionary of random KeyValue pairs) and IN expressions against integer nested properties e.g. $filter="metadata/intProp in (1,2)" used to work up until OData .NET v7.17.

Assemblies affected

Which assemblies and versions are known to be affected e.g. OData .Net lib 7.x
OData.Core .NET >= v7.18

Reproduce steps

https://gist.github.com/atomaras/335bda36b3c03faeddc4b66f2483386f

Expected result

Parsing should respond with a valid Node just like it did with previous versions.

Actual result

It started failing with the following error:

Additional detail

Optional, details of the root cause if known. Delete this section if you have no additional details to add.

[KenitoInc]

@atomaras
I have been unable to repro this issue.
I added a test. See commit

EntityType Person has an open complex type MyOpenAddress. I filter against dynamic property OpenProp property within MyOpenAddress.

Get /People?$filter=MyOpenAddress/OpenProp in ('123', '456')
I am able to parse the query correctly.

[atomaras]

@KenitoInc Notice in my repro gist how my filter looks like (it is targeting an integer property, not a string)

https://gist.github.com/atomaras/335bda36b3c03faeddc4b66f2483386f#file-odata-v7-18-regression-cs-L27

[atomaras]

Keep in mind that the reason this property is Open is because it is fully under the control of the clients of my API.
I (the API) do not and can not know what my clients are storing inside this metadata bucket.
So it is my clients responsibility to write the correct filter (string collection if the nested prop is a string or int collection if it is an int) and all I can do is trust it and pass is down the NoSQL database.

Now I have a bunch of clients who learned to pass int collections as filters for the int properties they store inside the metadata (because the OData v7.15 lib I shipped with was supporting it) so this change is a breaking change for all my clients.