Expr.reduce() incorectly cancels out the IN operator.

[pacesm]

Tested with version 0.4.1 in Python 3.12.12

Taking an example from from the CQL2 spec https://docs.ogc.org/is/21-065r2/21-065r2.html#advanced-comparison-operators, the IN predicate is completely eliminated by the Expr.reduce() operation:

>>> import cql2
>>> cql2.Expr("cityName IN ('Toronto','Frankfurt','Tokyo','New York')").reduce().to_text()
'false'

It looks like the reduction incorrectly treats the property identifier as a string literal (like 'cityName' IN ('Toronto','Frankfurt','Tokyo','New York')) and evaluates the whole predicate.

[alukach]

I agree that this seems strange. The logic of reducing in operations to a boolean is written here:

cql2-rs/src/expr.rs

Lines 448 to 452 in da1a804

	} else if op == "in" {
	let l: String = left.to_text()?;
	let r: HashSet<String> = right.try_into()?;
	let isin: bool = r.contains(&l);
	Ok(Expr::Bool(isin))

EDIT: Disregard any of the lower text. I missed the detail that the queryable in an array operation is expected to resolve to an array rather than a single value.

This appears to be pretty intentional and is as added in #55, but it's not clear to me as to why we'd want to treat in any differently than the other ARRAYOPS:

cql2-rs/src/expr.rs

Lines 59 to 60 in da1a804

	/// Array Operators
	pub const ARRAYOPS: &[&str] = &["a_equals", "a_contains", "a_containedby", "a_overlaps"];

ie

cql2-rs/src/expr.rs

Lines 437 to 439 in da1a804

	} else if ARRAYOPS.contains(&op.as_str()) {
	Ok(array_op(left, right, &op)
	.unwrap_or_else(|_| Expr::Operation { op, args }))

The syntax in JSON-format seems quite similar (not sure if that counts for much):

{
  "op": "in",
  "args": [
    {
      "property": "cityName"
    },
    [
      "Toronto",
      "Frankfurt",
      "Tokyo",
      "New York"
    ]
  ]
}

{
  "op": "a_contains",
  "args": [
    {
      "property": "values"
    },
    [
      "a",
      "b",
      "c"
    ]
  ]
}

@bitner @gadomski Do you have any thoughts?