estimate storage usage during garbage collect

Rational

Presently, garbage collection dry runs only provide us with information about which object would be garbage collected.

This MR would extend garbage collection to estimate the amount of storage that would be removed via a garbage collection run without having to switch the registry to readonly mode.

Changes

Add Scale, intended to mirror Vacuum, a struct with a method for determining the storage usage of a list of blobs.

Run this method after try run Mark Phases

Results

Here's some example logging from a dry run with these changes:

...

time="2020-01-24T00:25:49.041759844Z" level=info msg="mark stage complete" blobs_marked=15041 blobs_to_delete=360 duration_s=75.912496155 go.version=go1.11.13 instance.id=40e6a1cc-4b4b-45dd-b6da-90bd053659c0 manifests_to_delete=0 service=registry
time="2020-01-24T00:25:49.0418781Z" level=info msg="dry run: estimating how much storage would be freed" go.version=go1.11.13 instance.id=40e6a1cc-4b4b-45dd-b6da-90bd053659c0 service=registry
time="2020-01-24T00:25:49.141862953Z" level=info msg="blob info" digest=sha256:200ea72020e3865365fc468262ed1b32dcaf8e753e5dc1dadee5990c56b9fd8a go.version=go1.11.13 instance.id=40e6a1cc-4b4b-45dd-b6da-90bd053659c0 service=registry size_bytes=524690

...

time="2020-01-24T00:26:26.281495725Z" level=info msg="blob info" digest=sha256:e6b0c00dbfd7a15fdb3240d209aa0506098c4342b0024c84dc3b9a4aee4e1d25 go.version=go1.11.13 instance.id=40e6a1cc-4b4b-45dd-b6da-90bd053659c0 service=registry size_bytes=2048
time="2020-01-24T00:26:26.281569099Z" level=info msg="dry run complete" average_blob_size=105642 blobs_measured=360 duration_s=37.23968197 go.version=go1.11.13 instance.id=40e6a1cc-4b4b-45dd-b6da-90bd053659c0 service=registry total_size_bytes=38031123

Caveats

To measure the storage usage, scale sequentially stats each file in the delete set.

It's possible we could achieve a faster result using Walk, implementing a WalkFn which could potentially run in parallel, depending on the driver. I decided not to do this because the delete set is a subset of all the blobs and there would likely be far fewer network requests.

This MR doesn't count storage from manifests. This in the spirit of iteration and under the assumption that manifests consume far less storage than filesystem layers.