fix(filter): report an unknown property in arithmetic as unknown

[pdevito3]

For later consideration in a major version. Do not merge now. #134 restored the v1.14.2 behavior to keep v1.x compatible (restore commit a3a4d54). This PR re-applies the behavior of af5c3f7 (#113). The captain decides on this PR separately.

Summary

An unknown property in an arithmetic clause gets the same result as an unknown property in any other filter clause:

• If AllowUnknownProperties is false (the default), QueryKit throws UnknownFilterPropertyException.
• If AllowUnknownProperties is true, QueryKit ignores the clause. IgnoredClauseBehavior controls the result, like for other ignored clauses.

The changes:

• QueryKit/FilterParser.cs: a new FindUnknownArithmeticSegment walks both sides of the arithmetic comparison before the parser builds the expression.
• QueryKit/PropertyResolver.cs: Resolve now calls a new ResolveWithoutDepthCheck, so arithmetic can resolve a property without MaxPropertyDepth. The result of Resolve does not change.

v1.14.2 behavior (and main)

An unknown property in arithmetic throws ArgumentException ("Property 'Nope' not found on type 'TestingPerson'"). This also occurs when AllowUnknownProperties is true. A query name, a derived property, or a custom operation name in arithmetic also throws ArgumentException.

New behavior

Arithmetic supports only entity members. A name that is not a member is unknown:

• Without AllowUnknownProperties, the parser throws UnknownFilterPropertyException ("The filter property 'Nope' was not recognized.").
• With AllowUnknownProperties, the parser ignores the clause.

The check uses the same member lookup as other clauses. It does not apply MaxPropertyDepth (item P, #138) or PreventFilter (item I, #136).

Example

var config = new QueryKitConfiguration(config =>
{
    config.IgnoredClauseBehavior = IgnoredClauseBehavior.Remove;
    config.AllowUnknownProperties = true;
});
FilterParser.ParseFilter<TestingPerson>("""(Nope + 1) > 3 || Age > 100""", config);

• v1.14.2 and main: ArgumentException: Property 'Nope' not found on type 'TestingPerson'.
• This PR: x => (x.Age > 100).

Without the configuration, (Nope + 1) > 3 throws UnknownFilterPropertyException on this PR.

Justification

AllowUnknownProperties is documented as "unknown properties will be ignored". On v1.14.2, arithmetic ignores this setting. The README also says that an unknown filter property throws UnknownFilterPropertyException. On v1.14.2, arithmetic throws ArgumentException, so an API that maps QueryKitException to a 400 returns a 500 for this input.

Migration

• If your code catches ArgumentException for an unknown property in arithmetic, catch UnknownFilterPropertyException (or QueryKitException) instead.
• If you set AllowUnknownProperties, an arithmetic clause on an unknown property no longer throws. QueryKit ignores the clause.

README

The "Supported Features" list under "Arithmetic Expressions" gets one new item, "Unknown Properties". It states the exception, the AllowUnknownProperties result, and that arithmetic supports only entity members. The sections "Allow Unknown Properties" and "Error Handling" already describe the new behavior and do not change.

Interaction with other PRs

• I (fix(filter)!: apply PreventFilter and PreventSort to every property path #136) adds the same ResolveWithoutDepthCheck split and also edits the arithmetic Select. If both merge, the second one gets a text conflict. The combined code is the ResolveArithmeticProperties of main before fix: restore v1.14.2 behavior for every breaking change on main #134.
• P (fix(filter)!: apply MaxPropertyDepth to property paths in arithmetic #138) adds ResolveArithmeticProperties with a depth check. The same text conflict occurs.
• J5 and J-bis (fix(filter)!: resolve query names in the grammar again #154) make a query name in arithmetic resolve to its property. On this PR alone, a query name in arithmetic is unknown, so the pin query_name_in_arithmetic_throws changes (see Tests).

Tests

Unit (QueryKit.UnitTests/PropertyResolverTests.cs), from main before #134:

• unknown_property_in_arithmetic_throws_when_unknown_properties_are_allowed becomes unknown_property_in_arithmetic_removes_the_clause_when_unknown_properties_are_allowed.
• unknown_property_on_the_right_side_of_arithmetic_throws_when_unknown_properties_are_allowed becomes unknown_property_on_the_right_side_of_arithmetic_removes_the_clause_when_unknown_properties_are_allowed.
• unknown_property_in_arithmetic_throws_an_argument_exception becomes unknown_property_in_arithmetic_is_not_recognized.

Unit, changed for this PR alone:

• query_name_in_arithmetic_throws becomes query_name_in_arithmetic_is_not_recognized. It expects UnknownFilterPropertyException for (stars + 0) > 3, where stars is a query name. Main before fix: restore v1.14.2 behavior for every breaking change on main #134 resolved this query name (J-bis), so that test is not in this PR. If both PRs merge, keep the test of fix(filter)!: resolve query names in the grammar again #154: the query name resolves.

Integration (QueryKit.IntegrationTests/Tests/PropertyResolverTests.cs): unknown_property_in_arithmetic_removes_the_clause_when_unknown_properties_are_allowed comes back.

dotnet test: 470 unit tests and 298 Postgres integration tests (Testcontainers) pass, 0 failures.

Rebase on main

This branch is rebased on current main. The only conflict was in the integration tests, where main added tests at the same place.