The current streaming RPC, StreamDownloadLocations, was a straight translation of the unary RPC GetDownloadLocations. We added streaming because it found it interacted much better with TCP and HTTP/2 window scaling. At the time, the RPCs were no reworked to take advantage of the stateful nature of the stream. Since then, the pipelined ChunkFetcher machinery has been added, which makes opportunities for reuse on the individual streaming RPC even better. We also added the RefreshTableFileUrl endpoint, which decouples a client's ability to continue using previously communicated table files from its need to see them in a GetDownloadLocsResponse in particular.

StreamChunkLocations is transiting the exact same semantic payloads as StreamDownloadLocations. It's just not re-transmitting a bunch of stuff it does not need to. In particular:

1. We transit table file URLs separately from the chunk locations. A table_file_id is assigned to a table file the first time the server tells the client about it. Then that same table_file_id is used to refer to that table file for all communicated chunk locations in all response messages on the same stream.

2. We do not re-transit chunk hashes. The responses refer to the chunk hashes which were provided in the corresponding request by index. The client already knows them.

3. We do not need to transit RefreshTableFileUrlRequest messages for the table files. The client can build these with its own knowledge.

Those are three major improvements for bandwidth utilization. There are also some smaller things, like sending chunk_hashes as bytes instead of repeated bytes.

This PR adds a features field in GetRepoMetadataResponse. That field lets a client know that it can call the new available endpoint. Otherwise the client continues calling StreamDownloadLocations.

This PR adds both server-side and client-side implementations for the new endpoint. The server-side implementation ends up looking a lot like the existing StreamDownloadLocations code. It keeps some local maps so it can include the appropriate reference ids in the outgoing messages. The client-side implementation intentionally remains about as minimal as possible. In particular, it does not touch range coalescing or most aspects of the fetch pipeline. It targets just generating the StreamChunkLocationsRequest and handling the StreamChunkLocationsResponse messages. It translates the responses back into what StreamDownloadLocations would have generated before handing those pieces off to the rest of the fetch pipeline.

In addition to unit tests, some machinery in remotesrv is updated so we can optionally disable advertising support for StreamChunkLocations. This allows us to update some integration tests so that they continue to exercise the StreamDownloadLocations code paths on both the client and the server.