Add minimal, multi stream support to minimal-download client

[stephen-soltesz]

Previously, the minimal-download client only operated on a single stream. To contrast this tool with other multi stream tools, this change adds a minimal support for multi stream downloads.

The final download rate is currently calculated from the "first-open to first-close" time window.

For example:

$ minimal-download -duration 1s -streams 3
Connecting: wss://msak-mlab3-lga04.mlab-oti.measurement-lab.org/throughput/v1/download?...
Download client #1 - Avg  437.05 Mbps, MinRTT  4.55ms, elapsed 0.4319s, application r/w: 0/23595261
Download client #1 - Avg  484.26 Mbps, MinRTT  4.45ms, elapsed 0.8316s, application r/w: 0/50340258
Download client #1 - Avg  483.72 Mbps, MinRTT  4.45ms, elapsed 0.9366s, application r/w: 0/56634811
Download client #1 - Avg  491.40 Mbps, MinRTT  4.45ms, elapsed 1.0415s, application r/w: 0/63975876
Download client #1 - Avg  486.51 Mbps, MinRTT  4.45ms, elapsed 1.2245s, application r/w: 0/74464752
------
Download client #1 - Avg  490.41 Mbps, MinRTT  4.45ms, elapsed 1.1292s, application r/w: 0/69219792
Download client #1 - Peak 500.53 Mbps, MinRTT  4.45ms, elapsed 1.1057s, application r/w: 0/69178832

---

This change is 

[coveralls]

Pull Request Test Coverage Report for Build 7496086894

Warning: This coverage report may be inaccurate.

We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.2%) to 70.216%

---

Totals
Change from base Build 7480605258:	0.2%
Covered Lines:	877
Relevant Lines:	1249

---

💛 - Coveralls

[stephen-soltesz]

@robertodauria what do you think?

[robertodauria]

. "Peak" results are just marginally (but consistently) better for me - e.g. increase of 0.1 Mb/s over 60 Mb/s

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: complete! 1 of 1 approvals obtained (waiting on @stephen-soltesz)

---

cmd/minimal-download/main.go line 314 at r2 (raw file):

				case streamCount > 1 && stream == 0:
					// Only do this for one stream.
					s.mu.Lock()

Is locking needed here? s.firstStartTime is only written once before this loop starts. Are there cases where this access can lead to a race?

[stephen-soltesz]

Thank you!

Reviewable status: complete! 1 of 1 approvals obtained (waiting on @robertodauria)

---

cmd/minimal-download/main.go line 314 at r2 (raw file):

Previously, robertodauria (Roberto D'Auria) wrote…

Is locking needed here? s.firstStartTime is only written once before this loop starts. Are there cases where this access can lead to a race?

I think you're right. I think I was imagining the contention around lastStartTime. But you're right we're guaranteed that someone (maybe this thread) has already written this value and it won't be written again.