Include invalidation hash in asset content keys

[mischnic]

Closes #7524

Previously, the invalidation hash was included in the cache key of the asset itself (so for that {filePath, committed, contentKey, mapKey, ...} object), but not in contentKey (and the other keys). So when changing for example an included file, the new build would overwrite the cache entry for the previous build. This causes the problem described in the issue (when changing an included file, and then changing it back you don't get the original bundle output).

I think including the invalidation hash in for contentKey is what we want?

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[parcel-benchmark]

Benchmark Results

Kitchen Sink ✅

Timings

Description	Time	Difference
Cold	2.13s	+11.00ms
Cached	353.00ms	-4.00ms

Cold Bundles

No bundle changes detected.

Cached Bundles

No bundle changes detected.

React HackerNews ✅

Timings

Description	Time	Difference
Cold	10.48s	-167.00ms
Cached	499.00ms	+10.00ms

Cold Bundles

No bundle changes detected.

Cached Bundles

No bundle changes detected.

AtlasKit Editor ✅

Timings

Description	Time	Difference
Cold	1.14m	-454.00ms
Cached	1.60s	-18.00ms

Cold Bundles

Bundle	Size	Difference	Time	Difference
dist/workerHasher.11b8f69d.js	11.83kb	+0.00b	38.62s	+6.32s ⚠️
dist/media-viewer.a19e03bf.js	4.50kb	+0.00b	38.62s	+6.33s ⚠️
dist/media-viewer.21624a99.js	3.93kb	+0.00b	38.62s	+6.32s ⚠️
dist/card.47672f0e.js	2.04kb	+0.00b	38.62s	+6.32s ⚠️
dist/Modal.ca6d4d94.js	1.16kb	+0.00b	38.62s	+6.32s ⚠️

Cached Bundles

No bundle changes detected.

Three.js ✅

Timings

Description	Time	Difference
Cold	7.40s	+131.00ms
Cached	400.00ms	-20.00ms

Cold Bundles

No bundle changes detected.

Cached Bundles

No bundle changes detected.

Click here to view a detailed benchmark overview.

[devongovett]

Seems right. Ideally we'd make the invalidation hashes specific to each pipeline, but that's a separate issue.