feat(storage): make benchmark more robust on stalls

[coryan]

Change the benchmark to use a single queue (LIFO) with the set of
objects to download, and have all the threads service this queue.
Previously we separated the objects in groups and assigned them to
threads. The previous approach wastes threads if one (or a small
fraction) of the downloads gets stalled. I think the new approach better
models a well-designed application.

---

This change is 

[google-cloud-cpp-bot]

Google Cloud Build Logs
For commit: 02f004a5096e4afb7cac582e5683b2eaaec63c15

• Public Access Build Logs
• Cloud Build Console (requires auth)
• Kokoro Logs (requires auth)

ℹ️ NOTE: Kokoro logs are linked from "Details" below.

[codecov]

Codecov Report

Merging #7113 (02f004a) into main (ae0fbe6) will increase coverage by 0.00%.
The diff coverage is 96.07%.

@@           Coverage Diff           @@
##             main    #7113   +/-   ##
=======================================
  Coverage   94.49%   94.49%           
=======================================
  Files        1309     1309           
  Lines      113025   113035   +10     
=======================================
+ Hits       106801   106812   +11     
+ Misses       6224     6223    -1     

Impacted Files	Coverage Δ
...orage/benchmarks/aggregate_throughput_benchmark.cc	88.55% <96.07%> (+0.59%)	⬆️
...bigtable/examples/bigtable_hello_instance_admin.cc	81.31% <0.00%> (-2.20%)	⬇️
google/cloud/pubsub/samples/samples.cc	91.67% <0.00%> (-0.08%)	⬇️
.../cloud/storage/benchmarks/throughput_experiment.cc	74.87% <0.00%> (+0.50%)	⬆️
...le/cloud/storage/internal/curl_download_request.cc	89.15% <0.00%> (+1.20%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae0fbe6...02f004a. Read the comment docs.

[dbolduc]

Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @coryan)

---

google/cloud/storage/benchmarks/aggregate_throughput_benchmark.cc, line 257 at r1 (raw file):

Quoted 4 lines of code…

    std::transform(configs.begin(), configs.end(), tasks.begin(),
                   [&task](TaskConfig const& c) {
                     return std::async(std::launch::async, task, std::cref(c));
                   });

if you did something like this, you can get rid of thetask lambda:

std::transform(configs.begin(), configs.end(), tasks.begin(),
               [&iteration](TaskConfig const& c) {
                 return std::async(std::launch::async, &Iteration::DownloadTask, iteration, std::cref(c));
               });

The aesthetic judgment is up to you. I don't have a preference.

[coryan]

Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @coryan)

---

google/cloud/storage/benchmarks/aggregate_throughput_benchmark.cc, line 257 at r1 (raw file):

Previously, dbolduc (Darren Bolduc) wrote…

    std::transform(configs.begin(), configs.end(), tasks.begin(),
                   [&task](TaskConfig const& c) {
                     return std::async(std::launch::async, task, std::cref(c));
                   });

if you did something like this, you can get rid of thetask lambda:

std::transform(configs.begin(), configs.end(), tasks.begin(),
               [&iteration](TaskConfig const& c) {
                 return std::async(std::launch::async, &Iteration::DownloadTask, iteration, std::cref(c));
               });

The aesthetic judgment is up to you. I don't have a preference.

I am going to leave as-is, and probably change my mind later