Bundle-uri capability: Only advertise when bundle exist

This MR is a building block towards enabling bundle-uri feature.

Here we modify the way bundle-uri capability is advertised to the client to only make it so when a bundle exist for the given repository.

For SSH, this change does not provide much benefit since the whole packfile negociation flow is performed on a single connection. In other words, the flow starts when the client starts the upload-pack service, and it ends when the client received all the objects it needed.

For SmartHTTP, however, this is different. Each request/command sent by the client (ls-refs, bundle-uri, fetch) is sent on different, stateless, RPC calls. There is no way to know what command the client is sending to the git-upload-pack process until that process is actually started, which means that the Git config injected into the process must be computed in advance for every request; this implies computing the SignedURL of the bundle if it exist. By advertising bundle-uri capability only when a bundle exists for the given repository, we make sure the client won't send a bundle-uri command if no bundle exist.

This not only reduces by 1 the number of round-trip request and the number of Git config computation, but it also make it easier to monitor the use of bundle-uri feature, since now we can be sure that when a client sends the bundle-uri command, it is because:

1. A bundle exists
2. The server advertised the capability
3. The client support the capability

Thus, we now have a way to know if a client is using bundle-uri or not.

References: #6572 (closed)

.gitlab/issue_templates/Git Version Upgrade.md

@@ -17,7 +17,7 @@ Would be really nice to point out contributions made by the Gitaly team, if any.
 - [ ] Introduce the new bundled Git execution environment in the [Git package](/internal/git/execution_environment.go) behind a feature flag.
   - [ ] Create an issue for the rollout of the feature flag ([Reference](https://gitlab.com/gitlab-org/gitaly/-/issues/5030)).
   - [ ] Optional: Create a [change request](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#change-request-workflows) in case the new Git version contains changes that may cause issues.
-  - [ ] Roll out the feature flag.
+  - [ ] Roll out the feature flag (Announce to #g_gitaly and #g_git).
   - [ ] Default enable the feature flag once the upgrade is deemed stable. You can do this in same release that added the feature flag initially.
   - [ ] Remove the feature flag after there has been at least one release with the feature flag default enabled. This is not a requirement since we bundle Git with Gitaly, but more of a safety precaution taken to ensure there is sufficient time for rollbacks/reverts.