Port /dashboard/activity to GraphQL

What does this MR do and why?

Some of the design concepts we're exploring for the personalized homepage rely on using LLMs to summarize recent user activity. This information is currently only available within the /dashboard/activity page (i.e. as rendered HTML), which makes it difficult for us to extract the information for use in prototypes. This MR ports the event fetching logic over to GraphQL so we can more easily extract recent user activity for experimentation.

Key changes:

• Updates existing Types::EventType class to include project and target fields
• Adds resolver for union EventTargetType
• Adds several new types and resolvers for push event data
• Adds new activities field (as experimental) to CurrentUserType with associated type
• Adds new policy for PushEventPayload to allow publishing info over GraphQL

Open questions:

• I've added these new types and resolvers under the Users bounded context. Does that make sense? Is there a better home for these?
• The CurrentUserType#events field takes a scope argument that allows switching between personal events, events for followed users, events for your starred projects, and events for all projects you have access to. Is this the right approach? Or should these be separate fields or on a different base type?
  • After reviewing other GraphQL implementations, I introduced a new ActivityStream type with separate fields for personal events, followed user events, etc.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

• https://gitlab.com/gitlab-org/gitlab/-/issues/508933+
• Closes Surface activity stream in GraphQL API (#514809 - closed)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

query UserActivity {
  currentUser {
    activity {
    	myActivity {
        nodes {
          action
          target {
            ... on Issue {
              title
            }
            ... on MergeRequest {
              title
            }
            __typename
          }
        }
      }
    }
  }
}