metro-file-map: Give plugins getOrComputeFileData, record observed content

[robhogan]

#1944 lets FileSystem.lookup record what it observed, but a file found only goes in existence. A plugin's per-file data is derived from the file's contents, so reading it should be recorded in content, which is also invalidated by modification.

Plugins currently read their data from lookup()'s pluginData, and a lazy plugin calls processFile when that's undefined. Recording on either wouldn't be enough - on a warm start, or any read after the first, the data is already stored and processFile never runs.

This replaces both with getOrComputeFileData(path, observations?), on plugin init options and FileDataPlugin. It returns the stored data, or for a lazy plugin runs the worker in-band on a miss, and records the file in content either way. A missing path or directory is a result rather than an error, so a caller falling back to something else has still recorded it. Plugin lookup no longer returns data, so getOrComputeFileData is the only per-file read.

The motivation is package.json, which Metro currently reads with fs outside the file map, leaving nothing to record:

metro/packages/metro/src/node-haste/PackageCache.js

Lines 24 to 25 in 32ff3c9

	const readPackageJsonSync: ReadPackageJsonFn = absolutePackageJsonPath =>
	JSON.parse(readFileSync(absolutePackageJsonPath, 'utf8'));

Changelog: Internal

Test plan:
New unit tests. Nothing passes observations to this yet, so it's only reachable from tests until the package.json plugin follows.

[vzaidman]

What if the observations created via both lookup and lookupContent, i.e. run the following for a file:

lookup(filePath, observations)
lookupContent(filePath, observations)

shouldn't we then move the file path from "existence" to "content"?

[robhogan]

shouldn't we then move the file path from "existence" to "content"?

Yeah good question - there's an argument for that, but I think it's easiest + most performant if we treat all of these sets as write-only during file map access. content is just a stronger check in any case - deletions invalidate it anyway, so being in both existence and content is harmless.

I've change a comment that suggested they were mutually exclusive.

[robhogan]

Modified this a bit further - lookupContent (which I wasn't keen on) is now gone and the observations.content.add is now handled by the caller, which is still self-contained within the file map.