<!-- If possible, please select a relevant template from the "Choose a template" dropdown above. --> <!-- template sourced from https://gitlab.com/gitlab-org/gitaly/-/blob/master/.gitlab/issue_templates/Default.md --> Gitaly's [PackObjectsHook](https://gitlab.com/gitlab-org/gitaly/-/blob/5ed4b62734f8f32242c286a6b7ac00414a99f3cf/cmd/gitaly-hooks/hooks.go#L131) is not a standard hook who belongs to https://git-scm.com/docs/githooks. Instead, it is a special hook set by `uploadpack.packObjectsHook` configuration, ss explained in [git pack-object cache](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/design_pack_objects_cache.md?ref_type=heads#high-level-architecture). During a [customer incident](https://app.incident.io/gitlab/incidents/7653), we found high OS thread count on a customer's Gitaly node is being driven by PackObjectsHook, each consuming nearly 50 OS threads during Git upload-pack operations. This behavior is pushing system thread usage toward the configured limit, contributing to ongoing performance issues and apdex drops. We need a way to restrict how many threads a `PackObjectsHook` can trigger. Currently, there are 2 possible ways: 1. Add `GOMAXPROCS` when we invoke PackObjectsHook binary. 2. Or pass a limit as an argument and use `runtime.GOMAXPROCS(&limit)`