Misconfigured bundle-URIs on the server shouldn't break git-clone

A while ago we had an incident where git-clone failed: gitlab-org/quality/engineering-productivity/master-broken-incidents#10166 (comment 2321279581)

The error:

error: RPC failed; HTTP 500 curl 22 The requested URL returned error: 500
error: expected flush after bundle-uri listing
error: could not retrieve server-advertised bundle-uri list

This was caused by misconfigured bundle-URIs on the server.

Problem analysis

(as far as I understand it at the moment)

When cloning through HTTPS, Gitaly runs git-upload-pack(1) with --stateless-rpc. When the user clones, it first does a GET /ls-refs, at that point Gitaly told the process uploadpack.advertisebundleuris so it advertises the bundle-uri capability. Then upon receiving the next HTTP request POST /upload-pack the Gitaly process noticed there are no bundle-URIs are configured, so it did not announce that capability. When the client then sent the command=bundle-uri the server didn't know what to do with that and aborted. The client ceased the clone at that point.

The issue on our side is resolved, but I think the clone should not abort when bundle-URIs fails.