Constraint's value (de)serialisation

[iamafanasyev]

While I was playing around with "pre-compiled" segment/constraint evaluation to avoid auxiliary Expr representation/evaluation in runtime, I found constraint's value being actually deserialised inside conditions library. At the same moment, it comes from Flagr UI, where it's passed to the server as a JSON encoded value. And that has several implications:

• we don't have an option to match on these string values: ", \ (the only option to input it in Flagr UI — "\"", it goes to the server as "\"\\\"\"", which is would be matched only on \", but not ", as it does not deserialises strings according to the actual serialisation process, i.e. does not JSON decode them);
• same for the string values containing these values;
• the most disturbing matter — regexes, for regex constraint to comply with conditions it does not have be fully escaped inside external double quotes (e.g. .+@example\.com comes from Flagr UI as ".+@exmaple\.com" and is stored as "\".+@example\\.com\""), so it leads to <input>:1:11: invalid char escape error message each time Go scans/parses it, as it interprets \. as an invalid escaping ("correct" one .+@exmaple\\.com from Flagr UI would not match on "[email protected]", but only on "my@example\\.com").

Are backward compatibility concerns (current regexes?) big enough to keep deserialisation things as they are now?

If not

and it is acceptable to use robust JSON encode/decode schema, it looks promising to use predefined (parsed while cache evaluation) predicate functions for constraint matching:

BenchmarkEvalSegmentExpr-8                   	  169834	      7011 ns/op	    6943 B/op	     113 allocs/op
BenchmarkSegmentConstraintsMatchEval-8   	 1651634	       732.8 ns/op	       0 B/op	       0 allocs/op

(it is not actually a blocker for this evaluation refactor, but it is way more straightforward and simple, instead of backward compatible version)