Add alerting tests to ensure AAD isn't broken after any API calls

[mikecote]

No description provided.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[pmuellr]

Wondering what the context is, and if it is what I'm guessing, how we're going to test this.

I guess it boils down to "ensure AAD isn't broken", and AAD for what (actions, alerts, anything?). Which could mean the following, for actions:

• changing a config value will end up changing the encrypted versions of the secrets, to take into account config is used as AAD
• ensuring that you can't change a config value without also supplying the original (or new, doesn't matter) values for the secrets

[mikecote]

Yeah, it would be to make sure AAD isn't broken after any modifications to an alert or action. I've caught myself breaking the AAD in the enable alert API without integration tests catching it. The enable API would set enabled: true and not pass the remaining attributes and this caused the alert to become corrupt.

What I had in mind for tests was to add a specific test decryption API (within test fixture plugin or so) that would make sure the object could still be decrypted. We would then call this API after a test modifies an alert / action (which may be most of them or at least 1 per endpoint).

Sample place a route could be registered: https://github.com/elastic/kibana/blob/master/x-pack/test/alerting_api_integration/common/fixtures/plugins/alerts/index.ts#L16