Add Multiversion support to Pages internal API

What does this MR do and why?

Add Multiversion support to Pages internal API

With the work to introduce Gitlab Pages Multiple Versions, a project now have to support multiple PagesDeployment at the same time.

For this reason, instead of using ProjectPagesMetadatum#pages_deployment_id to identify valid deployment the PagesDeployment#deleted_at field was introduced.

Now, when multiple versions is enabled for the project, we're making all the active PagesDeployment available to GitLab Pages render.

Related to: #416494 (closed)

Changelog: changed

PS.: A big portion of the original change was extracted to: Serve pages deployments without going through P... (!135993 - merged)

Screenshots or screen recordings

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

Screen_Recording_2023-11-13_at_18.54.27

• I tried to edit the file without in edit mode 🙈
• The 404 in the recording is because I was faster the the deploy itself, that's why the reload made it work. 🏃

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. You need a license (https://about.gitlab.com/handbook/developer-onboarding/#working-on-gitlab-ee-developer-licenses)
2. You need GitLab Runner (https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/runner.md?ref_type=heads)
3. Enable pages_multiple_versions_setting feature flag
4. Create a public project using the html template (root/html for example)
   • the reason to be public is to avoid having to set Access Control
5. Run the pipeline on that project (to ensure the pages is created)
6. Navigate to Settings > Pages (http://gdk.test:3000/root/html/pages, for example)
   • Disable Force HTTPS (requires valid certificates)
   • Enable Use multiple versions
   • [optional] Click on the Access pages URL to see your GitLab Pages site 👀
7. Edit your gitlab-ci.yml adding the pages_path_prefix to the pages job:

    image: busybox
   
    pages:
      stage: deploy
      pages:
        path_prefix: "$PAGES_PREFIX"
      artifacts:
        paths:
        - public
      script:
      - echo "This pages version will have this prefix > $PAGES_PREFIX <"
      - echo "Pages accessible through > ${CI_PAGES_URL}/${PAGES_PREFIX} <"
      variables:
        PAGES_PREFIX: "" # no prefix by default (master)
      rules:
        - if: $CI_COMMIT_BRANCH == "master" # ensure to run on master (with default PAGES_PREFIX)
        - if: $CI_PIPELINE_SOURCE == "merge_request_event" # conditionally change the prefix on Merge Requests
          variables:
            PAGES_PREFIX: 'mr$CI_MERGE_REQUEST_IID' # prefix with the mr<iid>, like `mr123`

8. Create a merge request editing the public/index.html file
9. When the merge request pipeline finishes, access the pages link printed on the pages job output. It looks something like (with mr at the end): http://root.pages.gdk.test:3000/html/mr1

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.