Reland "Add quota usage details tests for all other storage backends."

[chromium-wpt-export-bot]

This is a reland of 548e7b5e622ad79155ff95ef26738d7a40fe9397

Original change's description:

Add quota usage details tests for all other storage backends.

IndexedDB test was included in parent CL.

Bug: 904000
Test:
Change-Id: Icc3462f13d0dce0197a8ec54f22d5ad794a51292
Reviewed-on: https://chromium-review.googlesource.com/c/1334659
Reviewed-by: Victor Costan <[email protected]>
Reviewed-by: Joshua Bell <[email protected]>
Commit-Queue: Jarryd Goodman <[email protected]>
Cr-Commit-Position: refs/heads/master@{#616398}

Bug: 904000
Change-Id: I507ec17eabc8e323a7c6418075d4be4787d4c5df
Reviewed-on: https://chromium-review.googlesource.com/c/1378805
Reviewed-by: Joshua Bell <[email protected]>
Commit-Queue: Jarryd Goodman <[email protected]>
Cr-Commit-Position: refs/heads/master@{#617285}

[wpt-pr-bot]

Already reviewed downstream.

[foolip]

Taskcluster flakiness in Chrome:

Test	Subtest	Results	Messages
/storage/estimate-usage-details-application-cache.https.tentative.html	estimate() shows usage increase after app is cached	FAIL: 9/10, PASS: 1/10	assert_greater_than: expected a number greater than 3372 but got 3372

[foolip]

@jarryd999 @inexorabletash, see #14531 (comment) for reported flakiness of estimate-usage-details-application-cache.https.tentative.html. Is this expected to happen on Chrome Dev because of some code change that hasn't reached the dev channel yet, or might there be a problem with the test?

[lukebjerring]

Tests were already flaky:
https://staging.wpt.fyi/results/storage?label=master&label=experimental&max-count=10&product=chrome&q=%28chrome%3Apass%7Cchrome%3Aok%29+%28chrome%3Atimeout%7Cchrome%3Aerror%7Cchrome%3Afail%29

[foolip]

I was able to reproduce the flakiness with the changes in this PR rebased on master (commit 27085bc) running ./wpt run --verify --channel dev --binary which google-chrome-unstable --log-tbpl - chrome /storage/estimate-usage-details-application-cache.https.tentative.html:

/storage/estimate-usage-details-application-cache.https.tentative.html

Subtest	Results	Messages
	OK
estimate() shows usage increase after app is cached	FAIL: 5/10, PASS: 5/10	assert_greater_than: expected a number greater than 3364 but got 3364

Confusingly, the same command on master seems to pass, but that's because the test didn't exist before.

[foolip]

Like in #15015, seeing consistent 5/10 fail makes me suspect there's no randomness to this, just some test/infra issue.

[foolip]

Ah, it is a lot like #15015. If the cache is global and the test runs in parallel, then only one of the tests will add to the size of the cache...

[foolip]

@jarryd999 @inexorabletash @pwnall, this hasn't been merged in wpt yet because of the flakiness, which I think is because the cache is shared.

Do you have thoughts on how to fix this issue? A fix like #15018 doesn't seem as straightforward here, I think one would need a unique appcache.manifest for each load? But how does appcache interact, is it even possible to install arbitrary number of appcaches for the same domain/path/something?

[foolip]

I've run while true; do ./wpt run --no-pause --channel dev --binary which google-chrome-unstable chrome /storage/estimate-usage-details-application-cache.https.tentative.html || break; done for a while (~15 loops) to confirm that this probably isn't flaky in the usual sense. I'll file an issue and admin merge.

[foolip]

Filed #15036.