Add alert type GraphQL query

[GregorShear]

Summary

• Add a new alertTypes GraphQL query that returns all possible alert types with user-facing metadata (title, description)
• Update subscription mutations to add system alerts to all subscriptions (i.e. system alerts are non-optional)

query {
  alertTypes {
    alertType,
    description,
    displayName,
    isDefault,
    isSystem
  }
}

NOTE: Pagination will not be implemented for this endpoint because of the simplicity of the data returned.

Issues

The issues directly below are completely resolved by this PR:
#2794

[jshearer]

• What are we doing about ShardFailed? Currently, we have been treating it as a beta feature that customers can opt into by asking us. This PR marks it as both default and system, meaning that not only is it on by default, you actually can't turn it off. That seems surprising. Did you talk about this w/ Dave?
• There are now two different sources of truth for the default alerts: this AlertType::is_default() and the database column defaults. And in fact since ShardFailed is marked as default in the PR, those are divergent now. Today, the DB column default is what gets used when provisioning new tenants. I note that despite introducing a concept called is_default, this PR doesn't actually change the behavior of the system to use it anywhere.
• How are we thinking about the migration here now that we're introducing is_system/is_default? Once we merge this, there will be a lot of existing tenants with, for example, missing alert subscriptions that are marked as is_system. Will they be able to... add them in the UI, but just not remove them? Or what happens if someone modifies this in the DB, which does happen.
• There's an implicit relationship between system and default alerts: every system alert is also necessarily a default alert, but not every default alert is necessarily a system alert. It might be worth modeling this, or at least commenting on it? WDYT?
• I don't love how the description string can be/is different from the doc-comment for these alerts. I wonder if there's any way you/Claude can find to "reflect" the doc comment here? If not no big deal, but IMO it would be worth at least trying.

Put another way, I don't think this is coherent with the existing architecture, and I'm asking you to re-think how it should work so we don't introduce competing concepts and tech debt.

[GregorShear]

• easy to remove shardFailed from the list of defaults
• let's remove that default list from the table column and count on the default behavior living in the gql resolver
• also easy to run a migration and add system alerts to all subscriptions (if Dave wants this)
• i had the same thought about the system -> default relationship. the model isn't perfect, but let's save that refactor for another day.
• fair point about doc comments- i'll just remove those. the user-facing description can be the single source of truth.
  @jshearer

[jshearer]

Okay, this is looking better. The last thing I was concerned about is that removing the default on public.alert_subscriptions will actually break certain POST /rest/v1/alert_subscriptions calls that rely on the default value for include_alert_types. But you say you checked and the UI is purely using gql to create alert subscriptions, so with that I think this is good to go 👍