Proposed architecture update (custom matchers)

[WVAviator]

Warning: 2am can't-sleep idea

• Create a custom Value variant, akin to serde_json::Value and serde_yaml::Value, MValue (short for match value)
• Include an additional MValue::Matcher variant, in addition to the usuals (Array, Object, String, etc)
• Write custom serde deserialization visitor for MValue to interpret values and any Matchers
• Instead of hard coding a Matcher enum, keep a global map of matcher strings to Matcher trait objects (MatcherMap)
• Objects with Matcher trait require implementing a method which takes in the proposed match MValue and returns true or false

The goal of the above architecture change is to ultimately be able to support externally defined custom matcher extension plugins. In the case of a custom plugin written in any language, it would consist of an executable that Capti can call, initially with a --registration argument to get information needed to register the matcher in the MatcherMap, and later be able to call the executable with the proposed match and expect a true or false value back (or perhaps a more complex response, in the case where the matching engine should continue evaluating).

Custom matchers could then be written in any language - wrapper APIs for TypeScript and Rust can be provided initially that allow the developer to define just two functions, and the wrapper would handle converting the result of those functions to the interface needed by Capti to utilize the matcher.