Reimplement Matcher with plugin instances support

[Berdir]

PR for #12

Can't comment on the diff, so opening the PR for that :)

[Berdir]

Nice work!

[mbovan]

Pushed the latest changes. Most of the @Berdir's suggestions are applied. Some part of them are skipped and set as todo's for followups. I added replies on the feedback comments. They are hidden now as diff is outdated. :D

Patches to apply for Collect and Inmail

Regarding tests, FieldMatcherTest is pasing, fixed some parts and commented out most of the code in DefaultEngineTest and MatcherTest classes. We have to see what we can use/need from those tests...

Followups: #17, #18

[mirodietiker]

Did a manual test...

After saving a matcher, the system states "The configuration has been saved." without any reference to the matcher saved. But i'm still on the matcher add form... So either a redirect is missing to the edit form, or to the overview form.

The threshold value (required) is not saved. I don't know why, but i can only enable the field name (string) to match. All others are disabled.

Other than creating a matcher, i don't know how i can test a matcher. Did you already provide the collect integration? I like to test it.

[mbovan]

@mirodietiker:

1. Added redirection to the matcher overview page.
2. Fixed threshold.
3. I think because String is the only field handler that is not broken. That is the same in 8.0.x branch, so I didn't make any fixes there in this issue.
4. There are patches for Collect/Inmail in my previous comment that should be applied. Then, you can enable collect_demo.
   • Patch for Collect
   • Patch for Inmail

[mbovan]

• Added fix for saving matcher configuration.
• Add/Edit Matcher form redirects on the same page.

Updated Collect patch (loading a matcher from configuration instead of hard-coding to inmail_individual) with these changes and changes made in Remove event-based processing issue:

• Collect CRM update patch
• Inmail CRM update patch