tests: fix flaky cache test

[connorjclark]

fixes #11772

[connorjclark]

could make the argument that this should be in a beforeAll. thoughts?

[patrickhulce]

I would make that argument yes :)

[patrickhulce]

I would make that argument yes :)

[patrickhulce]

wait hang on, how does this fix the flake...? isn't the problem that too much time elapses between now and the assertion which is still true? nevermind I gotcha :)

[connorjclark]

how does time pass if date.now is constant. sppoky time

[brendankenny]

so no to switching the audit off of Date and to request timing?

[brendankenny]

it seems like from

lighthouse/lighthouse-core/audits/byte-efficiency/uses-long-cache-ttl.js

Lines 118 to 124 in a938fc4

	const expiresHeaders = headers.get('expires');
	if (expiresHeaders) {
	const expires = new Date(expiresHeaders).getTime();
	// Invalid expires values MUST be treated as already expired
	if (!expires) return 0;
	return Math.ceil((expires - Date.now()) / 1000);
	}

auditing with -A would often mean headers hitting this branch would have a negative cacheLifetimeInSeconds, which we then discard down in

lighthouse/lighthouse-core/audits/byte-efficiency/uses-long-cache-ttl.js

Lines 222 to 228 in a938fc4

	// Ignore if cacheLifetimeInSeconds is a nonpositive number.
	let cacheLifetimeInSeconds = CacheHeaders.computeCacheLifetimeInSeconds(
	headers, cacheControl);
	if (cacheLifetimeInSeconds !== null &&
	(!Number.isFinite(cacheLifetimeInSeconds) || cacheLifetimeInSeconds <= 0)) {
	continue;
	}

so would never show up in the audit?

I realize this is expanding the scope of the intended fix, so this can also be a new issue :)

[connorjclark]

merging in interest of less flaky tests. i'll write a new issue but can't take it right away.