Pass Gitaly feature flags when sending repository information to KAS via gRPC

What does this MR do and why?

Currently there are two places where we provide repository information to KAS: via the traditional API and over gRPC. The repository information sent is not the same in both places:

• The former includes information about the currently enabled (gitaly) feature flags, while the latter does not.
• The latter includes the extra git_object_directory and git_alternate_object_directories fields, while the former does not.

Technically this is a typebug, but I don't know if there's been any user-facing impact (it has been this way for a long time and we never noticed).

To make these consistent, we now include this information in both places.

While we're here, remove some duplication in the REST API by using predefined helpers.

How to set up and validate locally

You will need a local cluster, and gitlab-k8s-agent enabled in your GDK.

1. Create a project, and register an agent (without a config file).
2. Using the supplied Helm command, install the agent into your local cluster. The agent should show as "connected" in the UI.
3. Commit a config file for the agent to the default branch (it can be empty).
4. In the agent logs (gdk tail gitlab-k8s-agent), there should be a line saying the agent has fetched the updated config file, and there should be no errors:

   2023-07-11_07:43:07.94381 gitlab-k8s-agent      : {"level":"info","time":"2023-07-11T17:43:07.943+1000","msg":"Config: new commit","grpc_service":"gitlab.agent.agent_configuration.rpc.AgentConfiguration","grpc_method":"GetConfiguration","agent_id":1,"project_id":"root/agent-project","commit_id":"b2cbf41a418b131a049e7d77fcefd76f9f9d2705"}

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.