* OK notifications using previous evaluation data
* copy rule.EvalMatches to avoid changes to the underlying array
* test cases added/modified
* delete trailing newline
* fix double newline in go import
* add change to the changelog
* specify that this only affects legacy alerting (changelog)
* use current eval data instead of prev eval data
* create evalMatch just once
* code comments, renamings, getTemplateMatches() function
* changelog and docs updated
* propagate notificationservice down to the notifiers
* replace dispatch in result handler
* remove dispatch from the rule reader
* remove dispatch from eval context
* remove dispatch from alerting usage
* remove dispatch from alerting usage
* remove dispatch from notifier
* attempt to fix tests in alerting
* hello linter, my old friend; also disable some tests for now
* use mocks to fix the tests
* resolving wire providers
* make linter happy
* remove yet another bus.dispatch
* fix tests using store mock
* Introduce PluginRequestValidator abstraction with a NoOp implementation
* Update PluginRequestValidator abstraction to use the dsURL instead
* Inject PluginRequestValidator into the HTTPServer and validate requests going through data source proxy
* Inject PluginRequestValidator into the BackendPluginManager and validate requests going through it
* Validate requests going through QueryMetrics & QueryMetricsV2
* Validate BackendPluginManager health requests
* Fix backend plugins manager tests
* Validate requests going through alerting service
* Fix tests
* fix tests
* goimports
Co-authored-by: Leonard Gram <leo@xlson.com>
This way we are able to edit notification behavior per notifier.
This would be usefull to let some notifiers send notifications,
even when the state doesn't change, or with custom condition.
Signed-off-by: Thibault Chataigner <t.chataigner@criteo.com>
