Draft: PoC for CI contribution framework

What does this MR do and why?

Related to #351779 (closed)

TODO:

• YAML syntax to include shared CI configurations (used component: just for the sake of PoC. We need to come up with a name)
• Database table and model for each shared component
• Mechanism to publish a component
• Mechanism to change component configurations
• Mechanism to update component when manifest changes
• Rudimentary display of available components.
• Pass and validate input parameters when including a component.

Screenshots or screen recordings

Example of how it could work in a real world:

include:
  - component: gitlab-org/mr-workflow@0.1.2 # appends `workflow:rules` 
  - component: my-org/echo@0.1.0
  - component: gitlab-org/dast@master

# The component only attaches a hidden configuration.
# The author decides where to use it.
my-echo:
  <<: .echo-job
  stage: build

# The component attaches a fully working job.
# The author can override some details.
dast:
  stage: test

deploy:
  stage: deploy
  trigger:
    include:
      # The component appends multiple jobs: staging, canary, production.
      # The author can decide to isolate these jobs as a child pipeline.
      - component: aws/deploy@1.0

How to set up and validate locally

1. Create a project my-org/echo under a new group my-org
2. Inside my-org/echo create a .gitlab-ci.yml:

echo:
  stage: test
  script: echo "Hello from a component"

3. Inside my-org/echo create a component.yml file:

name: Echo
description: Print something on screen
tags: [] # empty for now

4. Inside my-org/echo create a README.md file, ensuring to include How to use section:

include:
  component: my-org/echo@0.1.0

5. Create a tag 0.1.0 from the default branch.
6. Publish the component
7. Check that the component is published to the public catalog.
8. In a different project's .gitlab-ci.yml include the component to see it in action.

Update catalog:

1. Update the component.yml file.
2. Check in the catalog that the component metadata has been updated.

Restrict access:

1. Restrict the component to be published only to the internal org's catalog
2. When checking the list of components available for a given project only show public + internal components.
   • don't show internal components from other namespaces.

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.