Don't overwrite self.teams upon parsing responders in OpsGenie integration

[lstyles]

Description

Checklist

• I have reviewed the contributing guidelines.
• I have included unit tests for my changes or additions.
• I have successfully run make test-docker with my changes.
• I have manually tested all relevant modes of the change in this PR.
• I have updated the documentation.
• I have updated the changelog.

Questions or Comments

[jertel]

Thanks for submitting this. There are already extensive unit tests for this alerter, so adjusting one of them to send two alerts and then assert that the second one was unaffected by the first should (hopefully) be low-effort.

[lstyles]

Thanks. Updated, but the changes needed were a bit more extensive than I would have liked.

I've added a test for this particular issue, but had to make some other changes to tidy things up a bit. Some of the tests were checking for (what I think) were incorrect values and some others were checking properties on the alert object instead of mocked post request.

I've done the recipients as well.

Let me know what you think. Apologies if it is a mess, I've not done any Python dev prior to this.

[lstyles]

The top two lines prevent other tests from failing as missing responder_args no longer skips the execution.

The bottom two lines fix a scenario where responders contains a placeholder, but responders_args isn't configured in a rule at all. Previously, a text with placeholder would end up as a responder. Now, a warning will be shown and default_responders will be used instead.

[lstyles]

The two new tests could probably be named to better describe what they're doing:

• preserve_rule_config_upon_parsing_teams
• preserve_rule_config_upon_parsing_recipients
  or something like that

[nsano-rururu]

The change from opsgenie_default_receipients to opsgenie_default_recipients requires the following documents to be updated:
https://github.com/jertel/elastalert2/blob/master/docs/source/alerts.rst

[lstyles]

@nsano-rururu I've updated alerts.rst as well but only now realised it makes this a breaking change. I was looking at Elastalert(1) docs and saw the correct spelling there. Not sure what the right approach here is.

[nsano-rururu]

The next version, 2.21.0, will allow both the old setting name and the correct wording. However, if you use the old setting name, how about informing the user that the old setting value will be deleted when the logger reaches 2.25.0 every time an alert notification is sent?

[nsano-rururu]

For warning loggers, use elastalert_logger.warning.

example
https://github.com/jertel/elastalert2/pull/793/files

[lstyles]

I've put something together but on alerter initialisation instead of alert send. Deprecation logic feels more in place there vs having it in the alert method.

Edit: Just realised you've got a mechanism for that already. 👀
Edit2: Not anymore. Looks like it was temporary, but also slightly different scenario and on a rule level instead of alerter level. 🤷

[nsano-rururu]

Update CHANGELOG.md.

[nsano-rururu]

@jertel

Any other comments?

[jertel]

Looks good, thank you both. The schema.yaml is missing those two properties, as well as other OpsGenie properties. But that can wait for another PR since it's not directly related to this.

[lstyles]

#1543 schema update as a separate PR (1 - to not block this one, 2 - because I'm not 100% sure it's correct)