Rename category - Dependency Proxy

Why is this change being made?

We now have two similarly named features, called:

• Dependency Proxy (for containers)
• Dependency Proxy for packages (newly added)

However, the features were named several years ago before the vision for the Package stage was fully formed. Lately, we've been receiving feedback from customers (external and internal) that the names are confusing.

This MR proposes updating the name of the features to Virtual Registries to better align with industry naming conventions.

Renaming this feature will have significant implications for user perception, marketing, and the overall value proposition of the product.

1. Clarity and Intuitiveness - Dependency Proxy might imply a specific, technical role with a narrower focus, mainly caching or serving as an intermediary for dependencies. Virtual Registry, on the other hand, suggests a broader, more comprehensive functionality. It indicates the caching and proxying capabilities and the storage, management, and organization of artifacts.
2. Alignment with Industry Standards and Expectations - The term Virtual Registry aligns more closely with terminology used in the industry, especially by JFrog's Artifactory and GCP.
3. Future-proofing the Feature - As we develop and expand the capabilities of this feature, the name Virtual Registry provides room to grow without being limited by the narrower connotation of a proxy.
4. Simplifying Communication and Marketing - A clear and descriptive name like Virtual Registry simplifies marketing efforts and communication about the feature.

Process

Process for Renaming Features (handbook)

Approvals

Merge requests with changes to stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:

• Chief Product Officer @david (post MR link in chief-product-officer once all others have approved) add @gschwam for tracking
• PLT Leader relevant to the affected Section(s) @mflouton
• The Product Director relevant to the affected Section(s) @jreporter
• The Engineering Manager relevant to the affected Section(s) @crystalpoole
• The Senior Engineering Manager relevant to the affected Section(s) @sgoldstein
• Director of Product Design @vkarnes

**Note:**_ Chief Product Officer approval should be requested once all other approvals have been completed. To request approval, post the MR link in the #chief-product-officer channel tagging @david and cc'ing @Gena Schwam._

The following people need to be on the merge request so they stay informed:

• Chief Technology Officer @sabrinafarmer
• Development Leader relevant to the affected Section(s)
• VP of Infrastructure & Quality Engineering @meks
• VP of UX @ampesta
• Director of Technical Writing @susantacker
• Engineering Productivity
• The Product Marketing Manager relevant to the stage group(s)

After Approvals and Merge

• Create an issue in the gitlab-org/quality/triage-ops project to update GitLab Bot automation:
  • for Category change
  • for Stage or Group change
  • If label migration is required, please follow the self-serve instructions to get started on a one-off label migration MR
• Open an MR in the gitlab-org/gitlab project to update any reference of the previous group label to the new one
• Mention the product group Technical Writer to update the documentation metadata
• Share MR in #product, #development, and relevant #s_, #g_, and #f_ Slack channels /label handbook

---