Adds LIKE / NOT LIKE to the supported comparison operators for keyword

[Rasu-Dev]

search attributes, enabling substring (Contains) filtering:

• query: accept LikeStr/NotLikeStr; new like_pattern.go translates SQL LIKE patterns (%, _, escapes) for each backend
• elasticsearch: map LIKE to a wildcard query (NOT LIKE via must_not)
• sql: pass LIKE patterns through the SQL visibility converters
• scheduler: treat NOT LIKE as a negative ScheduleId operator in the schedule ID query rewriter

What changed?

Adds LIKE / NOT LIKE to the supported comparison operators for Keyword search attributes in visibility queries, enabling substring ("Contains") filtering, e.g.:

WorkflowType LIKE "%payment%"

• query: LikeStr/NotLikeStr added to supportedComparisonOperators. New ConvertLikePatternToESWildcard (like_pattern.go) translates SQL LIKE patterns to Elasticsearch wildcard syntax (%→*, _→?, escaping literal *, ?, \).
• elasticsearch: LIKE maps to a wildcard query on the keyword field; NOT LIKE wraps it in must_not (both the current and legacy converters).
• sql: LIKE/NOT LIKE pass through as native SQL LIKE comparisons. Restricted to Keyword attributes with a literal-string right-hand side; the user-supplied pattern is passed through unescaped since %/_ are the intended wildcards (both converters).
• scheduler: NOT LIKE is recognized as a negative operator in the ScheduleId query rewriter, matching the existing handling of != / NOT IN / NOT STARTS_WITH.

Why?

There is currently no way to filter visibility results by substring — Keyword attributes only support exact match and STARTS_WITH. This enables "Contains" filtering, surfaced in the UI by a companion PR that adds a Contains option to the search-attribute filter dropdown emitting LIKE "%value%": .

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

New unit tests: like_pattern_test.go (pattern translation incl. _, escapes, literal */?), ES converter tests (query_converter_test.go, converter_test.go), SQL converter tests (query_converter_test.go, query_converter_legacy_test.go), and schedule_id_query_rewriter_test.go. Existing converter tests updated for the expanded operator list.

Manually: built the server, ran locally, and verified LIKE / NOT LIKE queries return correct substring matches via both direct ListWorkflowExecutions queries and the companion UI's Contains filter.

Potential risks

• Elasticsearch performance: LIKE "%value%" becomes a leading-wildcard wildcard query, which cannot use the index prefix and scans terms — heavier than the existing STARTS_WITH prefix query on large visibility indices.
• Backend semantic differences: case sensitivity follows the backend — ES wildcard queries on keyword fields are case-sensitive, while e.g. MySQL's default collation makes LIKE case-insensitive, so the same query can match differently across visibility stores (an existing property of other string operators too).
• No ESCAPE clause on SQL LIKE: a value containing a literal %/_ is always treated as a wildcard; users cannot match those characters literally.
• Query-language surface: this expands the public visibility query grammar, which is hard to walk back once released.

[CLAassistant]

All committers have signed the CLA.