Add IN and ARRAY_CONTAINS_ANY (not publicly exposed)

[thebrianchen]

This is a combination of multiple ports and backports in the Android and web SDKs. Here are some of the main ones 1, 2, 3.

Some questions I ran into:

• Should I include the swift compile tests now, or wait until this is publicly exposed? If we're including the tests now, how do I import the internal header into swift?
• I'm running into an issue of how to get the type of the underlying value of a FieldValue. Because we pass the type in as a type_describer lambda, I'm not sure how to get the underlying value, which results in a confusing error message.
• Implementing findFilterOperator() from android was not worth the effort b/c of array passing in C++. After talking with Gil, we decided to just add checks for array and disjunctive operators into FSTQuery. The name I came up with could definitely be better. Please advise :D

[wilhuff]

Please add a comment describing what this does. From its name I'm not really sure what it does at all.

[wilhuff]

Given this comment and the way you're using it. I'm not entirely sure I understand why this name is associated with "DocumentId". Your description doesn't mention it. Fundamentally this name is problematic because there's never really such a thing as a "document ID value". Document IDs are associated with the field of a filter, not the value.

Some ideas for how to resolve this (assuming I'm even understanding correctly):

1. Since your description is "Parses the given FieldValue into a Reference", shouldn't this name be something like ParseReferenceValue or maybe ParseExpectedReferenceValue?

2. Or maybe the issue is that we're parsing a reference value because we're expecting that whenever you supply a value for a document ID field? In that case you might consider naming this ParseValueForDocumentIdFilter or something like that.

[thebrianchen]

Thanks for breaking it down. The intention is that this method is called to validate that a provided FieldValue is indeed a valid Reference value, since References can also be Strings.

In that case, it makes sense to call it ParseExpectedReferenceValue, since we are parsing that an "expected" Reference value is actually a valid Reference value.

[wilhuff]

Given this comment and the way you're using it. I'm not entirely sure I understand why this name is associated with "DocumentId". Your description doesn't mention it. Fundamentally this name is problematic because there's never really such a thing as a "document ID value". Document IDs are associated with the field of a filter, not the value.

Some ideas for how to resolve this (assuming I'm even understanding correctly):

1. Since your description is "Parses the given FieldValue into a Reference", shouldn't this name be something like ParseReferenceValue or maybe ParseExpectedReferenceValue?

2. Or maybe the issue is that we're parsing a reference value because we're expecting that whenever you supply a value for a document ID field? In that case you might consider naming this ParseValueForDocumentIdFilter or something like that.

[wilhuff]

LGTM