[Alerting] Add list of valid connectors to alerting rules docs

[dedemorton]

Updates stateful docs for #3659.

This change needs to be ported to serverless, too. I'm going to wait on porting this to serverless because I need to cleanup inconsistencies first and sync with Lisa on how to best handle the connector links.

TODOs:

• Add list of supported connectors.
• Verify that all connectors in the list are supported for each rule.

[github-actions]

A documentation preview will be available soon.

• 🔨 Buildkite builds
• 📚 HTML diff
• 📙 Preview page

Request a new doc build by commenting

• Rebuild this PR: run docs-build
• Rebuild this PR and all Elastic docs: run docs-build rebuild

_{run docs-build is much faster than run docs-build rebuild. A rebuild should only be needed in rare situations.}

_{If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here.}

[mergify]

This pull request does not have a backport label. Could you fix it @dedemorton? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-/d./d is the label to automatically backport to the /d./d branch. /d is the digit
  NOTE: backport-skip has been added to this pull request.

[dedemorton]

@lcawl I need you input on a couple of things:

• What do you think of providing links to the connector docs (as I've done in this PR)? The benefit is that it shows all valid connectors for the observability alerting rules. The downside (as always) is maintenance, but since all the observability alerts seem to support the same set of connectors, it doesn't seem like a big challenge, and it helps users find the info in the Kibana docs.
• It seems like the docs have diverged a lot in how we introduce the concept of connectors (obs guide vs serverless vs Kibana). What do you prefer? I don't have time to do a lot of reconciling/consistifying right now.

[lcawl]

• What do you think of providing links to the connector docs (as I've done in this PR)? The benefit is that it shows all valid connectors for the observability alerting rules. The downside (as always) is maintenance, but since all the observability alerts seem to support the same set of connectors, it doesn't seem like a big challenge, and it helps users find the info in the Kibana docs.

I think like you said the trick will be keeping that list up-to-date. Connectors come into the platform from many directions (e.g. user-contributed or initiated by the responseOps team or by one of the solution teams), so they sometimes sneak up on me. As long as this Observability-specific list is somewhere we know to update every time a new connector is added, it shouldn't be too bad, however.

• It seems like the docs have diverged a lot in how we introduce the concept of connectors (obs guide vs serverless vs Kibana). What do you prefer? I don't have time to do a lot of reconciling/consistifying right now.

I think it's more divergent than ever now because (at least the last time I checked) in Serverless, each solution/project has a different subset of connectors that it supports. So this will definitely require some thinking once we get our connector pages migrated into docsmobile (i.e. are there some that apply to multiple projects, will this change over time, how does this affect their placement in the navigation?). Connectors are also used by cases, so we don't want to tie connectors exclusively to our rule-related content.

It used to be that after you'd chosen a connector, the action-related options you'd see would also vary depending on your rule type (e.g. can you do action summaries, can you specify a time filter or additional KQL filters, etc) but that disparity is disappearing as we roll out the "alerts as data" features across all the solutions. I think we still won't be able to cut and paste the same info across all rules (or if we do, we'll still need rule-specific screenshots), however, because the default message that appears in each rule (and the specific action variables it contains) differs for each rule. If you want to chat further about the short-term and long-term ways we can improve on this, I'm game.

[dedemorton]

I should have clarified that my main goal here is to remove the screen capture and replace it with a list because the screen capture doesn't show anything unique about the UI. It seems like the main purpose is to identify the list of valid connectors, but that means the info isn't accessible for the visually impaired. So, I've added a list with links and removed the screenshots.

After we have a clear content strategy for shared content, we'll probably need to revisit this decision. I'm going to mark this as ready for review with the understanding that we may take a different tack after we've had a chance to put more thought into how all the Alerting docs should work together and be supported by shared info (like the connector docs).