Add dap_unfiltered_clone flag for unfiltered DAP session clones

What does this MR do and why?

Duo Agent Platform (DAP) session environments currently clone with --filter=blob:none (blobless partial clone). Every blob the agent touches afterwards is backfilled with an on-demand fetch, which multiplies requests against Gitaly, and filtered clones cannot be served from the Packhorse pack cache. On heavily cloned repositories this contributes to pack-objects concurrency saturation and resource exhausted load-shedding while sessions start (see #627944).

This MR introduces the dap_unfiltered_clone feature flag (gitlab_com_derisk, default disabled, per-project actor). When enabled for a project, its DAP session jobs:

• clone without --filter=blob:none (GIT_FETCH_EXTRA_FLAGS becomes --prune --quiet; GIT_DEPTH=0 is unchanged), and
• fetch the base branch ref without a blob filter.

The larger initial fetch is cacheable by Packhorse and needs no backfill fetches, reducing sustained Gitaly load for projects with heavy clone traffic. Default behavior (flag off) is unchanged. The plan is for this feature flag to be turned on for GitLab.org/gitlab to see whether it relieves gitaly pressure.

The flag is deliberately not named dap_full_clone: that flag previously gated full-history (still blobless) clones and was removed in 97de8003 after reaching 100%, so lingering gates could have enabled the new behavior unexpectedly.

References

• Relates to #627944
• Same load-shedding failure mode for CI pipelines: #627739

Before	After

|

How to set up and validate locally

1. Start a DAP session (e.g. the Developer flow) on a project and confirm the job log shows a blobless fetch.
2. Enable the flag for the project: Feature.enable(:dap_unfiltered_clone, project)
3. Start another session and confirm the fetch runs without --filter=blob:none. Clone isn't visible in job runner logs.

Rollout checklist

• Enable dap_unfiltered_clone for gitlab-org/gitlab on GitLab.com and monitor Gitaly pack-objects saturation / ResourceExhausted rates
• Roll out to other high-traffic projects as needed
• Follow-up: add a rollout_issue_url and remove the flag once the default clone strategy is decided