fix: data filter != comparator should require NO matches (NOT IN behavior)

[uptownhr]

Summary

Fixes #3808

This PR fixes the != comparator in DataFilter to implement true "NOT IN" semantics when used with multiple values.

Problem

The != comparator was exhibiting unintuitive behavior:

• Before: Passed on first mismatch (value != ANY item in array)
• After: Passes only if NO matches found (value NOT IN array)

Example of the Bug

With comparator: "!=" and value: ["id1", "id2", "id3"]:

Event: {"brandId": "id1"}

• ❌ Old behavior: PASSES (because "id1" != "id2" is true)
• ✅ New behavior: FAILS (because "id1" IS in the array)

Changes

Code Changes

• pkg/sensors/dependencies/filter.go:
  • Added special handling for NotEqualTo comparator in JSONTypeNumber case
  • Added special handling for NotEqualTo comparator in JSONTypeString case
  • Both now check ALL values before deciding (true NOT IN semantics)
  • Other comparators maintain existing behavior

Test Coverage

• pkg/sensors/dependencies/filter_data_test.go:
  • Added 4 new test cases proving the fix:
    1. String filter with value IN array (should FAIL)
    2. String filter with value NOT IN array (should PASS)
    3. Number filter with value IN array (should FAIL)
    4. Number filter with value NOT IN array (should PASS)

Test Results

$ go test ./pkg/sensors/dependencies/...
PASS
ok  	github.com/argoproj/argo-events/pkg/sensors/dependencies	0.010s

All existing tests pass with no regressions.

Breaking Change Note

This is technically a breaking change as it modifies the behavior of the != comparator with multiple values. However:

1. The previous behavior was essentially broken/unusable
2. No test coverage existed for this scenario (suggesting low/no usage)
3. The new behavior matches intuitive expectations

Implementation Details

The fix checks if comparator is NotEqualTo and if so:

1. Scans through ALL values in the array
2. Tracks if ANY match is found
3. Only passes if NO match was found (true NOT IN)

For all other comparators, the existing logic is preserved (pass on first match).

[whynowy]

Thanks for raising the PR. Couple of questions:

1. Shall we introduce a new comparator for not in, like !in, !()?
2. Can this problem be solved by using other filters like expr or script?

[uptownhr]

Thanks for raising the PR. Couple of questions:

1. Shall we introduce a new comparator for not in, like !in, !()?
2. Can this problem be solved by using other filters like expr or script?

1. good question - I'm thinking given = already does in, it makes more sense to have != be not in.
2. i am currently using expr to get around this - but it would have been nice if != worked as I imagined.