Make project cloning faster in workspaces

MR: Add shallow cloning option for workspaces (!194906 - merged)

FF Rollout Issue: Workspaces shallow clone project FF rollout (#550330 - closed)

To improve performance and reliability when cloning large repositories, we should implement a cloning strategy that starts with a shallow clone (e.g. --depth=1). This will reduce initial data transfer and speed up workspace startup times.

Proposal

• Check out https://github.blog/open-source/git/get-up-to-speed-with-partial-clone-and-shallow-clone/ and decide if we need to perform shallow clone or partial clone and what is the best approach in our case.

Related to: Technical solution for "Enable MR review using ... (gitlab-org/quality/engineering-productivity/team!249 - closed)

Related Issues

Note that this is going to be a more minimal implementation of the larger scope of cloning configuration, which is covered by Allow configuration of project cloning approach (#414011 - closed) • Unassigned • Backlog

Acceptance Criteria

• Add new feature flag of type beta scoped to the project of the workspace
• Feature flag should be disabled by default
• Shallow clone with depth 30 (last 30 commits) if feature flag is enabled
• Unshallow the project in the background after initial project clone is complete
• Update the workspace docs, document the feature and mention that is controlled by a feature flag.
• MR must have the ~“feature flag” label assigend
• Create a rollout issue with this template and rollout changes to select Gitlab users
• Feature flag rollout should be used with an actor

Implementation Plan

• Introduce a new feature flag: workspaces_shallow_clone_project
• Pass in a boolean variable (value is set based on feature flag) to the cloning script internal_poststart_command_clone_project.sh that lets us determine if we want a shallow clone or full clone
• If variable is set to true - Add the depth flag --depth 30 to git clone --branch "%<project_ref>s" "%<project_url>s" "%<clone_dir>s"
• If feature is enabled - Add a new internal postStart script that is executed right after the internal_poststart_command_clone_project.sh script completes. The new script will be backgrounded and it will start the unshallow process and then allow the other internal postStart scripts to continue execution.
• If feature is not enabled - Keep the default cloning strategy as is (full clone)
• NOTE: Showing the status of the unshallow-ing to the user is out of scope of this issue.