fix(server): skip unsafe count optm for nested predicates

[lokidundun]

Purpose of the PR

• close [Bug] Wrong result for where(count().is() #3085

Main Changes

• Avoid applying HugeCountStrategy to count().is(...) traversals
  containing nested connective predicates.
• Keep the original CountGlobalStep + IsStep traversal for nested
  predicates, so that TinkerPop evaluates the complete predicate tree.
• Preserve the existing optimization for simple predicates and flat
  connective predicates.
• Prevent partially analyzed nested predicates from being transformed
  into RangeGlobalStep or NotStep, which can change or invert the
  filtering semantics.
• Add regression tests for a nested connective predicate and its
  negated form.

Verifying these changes

• Trivial rework / code cleanup without any test coverage. (No Need)
• Already covered by existing tests, such as (please modify tests here).
• Need tests and can be verified as follows:
  • xxx

Does this PR potentially affect the following parts?

• Dependencies (add/update license info & regenerate_known_dependencies.sh)
• Modify configurations
• The public API
• Other affects (typed here)
• Nope

Documentation Status

• Doc - TODO
• Doc - Done
• Doc - No Need

[imbajin]

Blocking: yes. Summary: Flat connective count predicates remain semantically unsafe and can return incorrect results after the destructive NotStep rewrite. Evidence: exact-head control-flow review and two independent TinkerPop 3.5.1 reproductions.

[imbajin]

‼️ Critical: flat connective predicates remain semantically unsafe

This guard only rejects a ConnectiveP whose child is another ConnectiveP, so flat expressions such as P.eq(0L).and(P.gt(0L)) and P.lte(0L).or(P.gte(1L)) still enter the optimization. The loop then derives useNotStep from only the first range-driving child and removes the complete count().is(...); on an empty adjacency the contradiction can return true, and on a non-empty adjacency the tautology can return false. Both shapes were reproduced against the current strategy on TinkerPop 3.5.1. Please disable the destructive rewrite for every ConnectiveP unless equivalence is derived from the complete boolean expression; the conservative fix is to skip all ConnectiveP values here. Add flat AND/OR regressions for both zero and nonzero counts.

[lokidundun]

This ci failure is not from this PR.HugeCountStrategy only fires on Gremlin traversals with count().is(...), but KoutTraverser uses HugeGraph's own BFS framework (no Gremlin traversal at all). The change only skips more cases,.

[imbajin]

Blocking: yes. Summary: The blanket ConnectiveP guard fixes the incorrect-result cases, but it also removes safe range limiting for common flat count predicates and can turn bounded counts into full scans. Evidence: exact-head control-flow inspection, confirmed independently by two review lanes.

[imbajin]

⚠️ Important: preserve safe range limiting for flat connective predicates

Returning here for every ConnectiveP bypasses the entire strategy, including the safe RangeGlobalStep insertion. Common predicates such as between(1, 18) are connective predicates, so a high-degree count().is(...) traversal now counts the complete input instead of stopping at the upper threshold. The new result assertions do not detect this plan regression. Please keep disabling the destructive NotStep/dismissCountIs rewrites unless full-expression equivalence is proven, while retaining a proven-safe range cap for analyzable flat connectives (and continue skipping nested cases as needed). Add a traversal-plan regression that asserts a representative flat connective still receives the range bound.

[imbajin]

Blocking: no. Summary: The current head preserves safe range limiting for flat connective predicates while bypassing unsafe nested predicate rewrites; no actionable issues were found. Evidence: CountStrategyCoreTest passed 35/35 on the exact head, and all 15 visible latest-head checks succeeded.