Deprecate pipelines in packages related GraphQL types

🍍 Context

When a package is pushed to the GitLab Package Registry from a CI job, the Package Registry will record a "link" between the package model and the CI pipeline object. This is for audit reasons (to be able questions like: how was this package pushed to the registry?).

Here is the (simplified) tables schema:

flowchart TD
    packages_build_infos --> packages_packages
    packages_build_infos --> ci_pipelines

The link is modeled quite simply. We have a build infos (table packages_build_infos) object that has two belongs_to statements that will reference a package (table packages_packages) and a pipeline (table ci_pipelines).

On the package model, to ease the object navigation, we have these statements:

has_many :build_infos, inverse_of: :package
has_many :pipelines, through: :build_infos, disable_joins: true

During our database decomposition analysis, we observed that using a disable_join: true option in that has_many :pipelines, through: :build_infos statement was going to bring some potential issues depending on type of access done.

One of the problematic access are GraphQL APIs. From the analysis:

GraphQL package -> pipelines

🐛 Can load an unbounded amount of pipeline ids in memory

GraphQL project -> packages -> pipelines

Existing 🐛 We load an unbounded amount of build_info and pipelines in memory.

GraphQL group -> packages -> pipelines

Existing 🐛 We load an unbounded amount of build_info and pipelines in memory.

While working on limiting the number of build info loaded during GraphQL queries (for a single page), we challenged the fact of having a pipelines field in package related types. The result of that discussion is that we could work with having only the build info objects in graphQL and not link the pipelines directly package related types.

The plan of this change is laid out in this epic: &7214 (closed).

This MR is the very first step of that plan: deprecating the pipelines fields in the package related GraphQL types, so that we can remove them in %15.0.

The work of this first step is captured in issue #347219 (closed).

What does this MR do and why?

• deprecate the pipelines fields in the package related GraphQL types.

Screenshots or screen recordings

Using the graphql explorer:

How to set up and validate locally

1. Navigate to the graphql explorer: /-/graphql-explorer
2. Open the PackageTye (or PackageDetailsType)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.