feat(config)!: put the parse limits on IQueryKitConfiguration

[pdevito3]

For later consideration in a major version. Do not merge now. #122 moved these members off the interface to keep v1.x non-breaking. This PR puts them back.

Summary

 public interface IQueryKitConfiguration
 {
     ...
     public int? MaxPropertyDepth { get; set; }
+    public int MaxNestingDepth { get; set; }
+    public int MaxInputLength { get; set; }
     public CaseInsensitiveMode CaseInsensitiveComparison { get; set; }
 }

-public interface IQueryKitParseLimits { int MaxNestingDepth; int MaxInputLength; }
-public class QueryKitConfiguration : IQueryKitConfiguration, IQueryKitParseLimits
+public class QueryKitConfiguration : IQueryKitConfiguration

 FilterParser.EnsureWithinInputLength
-  maxLength = (config as IQueryKitParseLimits)?.MaxInputLength ?? QueryKitSettings.DefaultMaxInputLength
+  maxLength = config?.MaxInputLength ?? QueryKitSettings.DefaultMaxInputLength
 FilterParser.ParseFilter
-  _maxNestingDepth = (config as IQueryKitParseLimits)?.MaxNestingDepth ?? QueryKitSettings.DefaultMaxNestingDepth
+  _maxNestingDepth = config?.MaxNestingDepth ?? QueryKitSettings.DefaultMaxNestingDepth

• v1.14.2: IQueryKitConfiguration has no limit members.
• New: IQueryKitConfiguration has MaxNestingDepth and MaxInputLength. The parser reads the limits from any configuration that is not null. IQueryKitParseLimits is removed.
• Why: Every configuration exposes the parse limits in one place. A custom configuration controls its own limits, and it does not silently get the defaults.

Evidence

A consumer class that implements every v1.14.2 member:

public class MyConfiguration : IQueryKitConfiguration { /* v1.14.2 members */ }

• v1.14.2 and main: compiles and runs.
• This PR:
  • Source break: error CS0535: 'MyConfiguration' does not implement interface member 'IQueryKitConfiguration.MaxInputLength'.
  • Binary break (library compiled against v1.14.2): System.TypeLoadException: Method 'get_MaxNestingDepth' in type 'MyConfiguration' ... does not have an implementation.

Tests in ParseLimitsTests.cs, changed from the restore tests:

configuration_that_implements_the_interface_uses_its_own_limits
  InterfaceOnlyConfiguration { MaxNestingDepth = 2 }, filter with 3 nested groups
  -> throws QueryKitNestingDepthExceededException "... depth of 3 ... maximum allowed depth of 2"
configuration_that_implements_the_interface_uses_its_own_input_length
  InterfaceOnlyConfiguration { MaxInputLength = 10 }, longer filter
  -> throws QueryKitInputLengthExceededException

dotnet test on this branch: 470 unit tests and 297 integration tests pass, 0 failures.

Rebase on main

This branch is rebased on current main. Main now counts the nesting depth in the grammar (#157), so the parser reads MaxNestingDepth in ParseFilter. The change of this PR is the same.

• InterfaceOnlyConfiguration in FilterBehaviorInterfaceTests.cs implements IQueryKitConfiguration directly. It now gives both limits, with the QueryKitSettings defaults.
• The main test configuration_that_implements_only_the_interface_has_no_limits is removed. With this PR, a configuration without the limit members does not compile.
• The README section "Parse Limits" now names IQueryKitConfiguration, not IQueryKitParseLimits.

Merge Danger

Door: one-way

After a release, consumers implement the two members. A later removal is a second break.

Blast Radius: consumers

• Only classes that implement IQueryKitConfiguration directly break. A subclass of QueryKitConfiguration does not break.
• Trap after the obvious source fix: auto-properties default to 0. Then every filter throws QueryKitInputLengthExceededException: ... maximum allowed length of 0. The release notes must tell implementers to return QueryKitSettings.DefaultMaxNestingDepth and QueryKitSettings.DefaultMaxInputLength.
• Code that references IQueryKitParseLimits stops compiling.