Discovery new DiscoveryConfigChangeEvent definition

[charlestp]

This implementation will replace the old DiscoveryConfigEvent. I made a new event since merging into the old event would result in a lot of confusing variations of fields. The new events carries more information that will be useful for product analysis.

• which client kind made it
• setup attempt ID so frontend events can be correlated all the way through to backend resource events.
• separate cloud providers and cloud resource types for easier joining and aggregation.
• enum types instead of strings

I'm planning to delete the old event in a follow-up PR.

setup_attempt_id will get plumbed through with the frontend events work in a follow-up PR.

Manual Test Plan

Test Environment

Locally

Test Cases

• New event is emitted with the expected fields

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 94f7593dbb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Submit the new event from mutation handlers

Every successful DiscoveryConfig mutation still calls the old emitUsageEvent (lib/auth/discoveryconfig/discoveryconfigv1/service.go:222,270,315,358), and a repo-wide search finds NewDiscoveryConfigChangedEvent only here and in its test. Consequently, tp.discovery.config.changed has no producer, so none of the new action, client, setup-attempt, matcher, or Access Graph data is ever reported; wire this constructor into the create, update, upsert, and delete paths with their request context.

Useful? React with 👍 / 👎.