manager.go

When a client performs a git-clone (SSH or Smarthttp)
Gitaly instructs the `git-upload-pack` command to
systematically advertise the bundle-uri capability.

This situation causes the Git client to request a
bundle-uri even when one does not exists, thus adding
unnecessary latency to the overall `clone` operation.
It also makes it hard to properly monitor the usage
of bundle-uri by clients; we can't correlate a request
for bundle-uri with an actual usage of it.

The proposed changes have the `git-upload-pack` command
advertise bundle-uri only when a bundle exists for the
given repository.

More context:

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.

For SmartHTTP it not only reduces by 1 the number of round-trip
request and the number of Git config computation, but it also
makes it easier to monitor the use of `bundle-uri` feature, since
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

References:
#6572