improvement(fluid-build): Use hash-based caching in Biome task

[tylerbutler]

We've observed that the Biome fluid-build tasks are often triggered when they shouldn't be. The problem seems to be in the file modified time, which doesn't match expected, implying a "rogue" process has touched a file.

I added the ability to use a content-based hash instead of the file stats in a previous change, so I just updated the task to use it. This sidesteps any issues with the stats-based approach.

This mechanism is ~20% slower than the stats-based approach, but tasks with few files/smaller files are less affected. The Biome task is most affected because it effectively caches every file in the path. #21826 will add support for ignore files in the Biome task, which should limit the perf hit for that task.

The Biome task was introduced without content-based caching and that is different than the Prettier task behaved. With this change the behavior should match the Prettier task more closely and should get us back to a known good config.

[jason-ha]

I think the change description should be updated to note that Biome was introduced without content checking and that is different than Prettier was setup. More or less matching Prettier task should get back to a situation that appeared to be working.

[jason-ha]

Definitely need comments in BiomeTask that the done file tracking is too expansive.

[tylerbutler]

Definitely need comments in BiomeTask that the done file tracking is too expansive.

Added in latest.

[jason-ha]

Just to state my current thoughts on this PR (why I haven't approved; as discussed in Teams thread):
The TypeValidationTask use of hashes is not a confirmed fix. We don't know the root source of why the timestamps are changed and we can't say that content capture will address the issue. It is possible that it will further hide the root cause. For example, if there is an async write happening, then the content capture may sometimes get the before content and sometimes after content. If those are different, then sometimes the hashing won't work.
For Biome the use of hashes is probably okay. In that case we know that type test generation is throwing it off because it is looking at those files even though it doesn't rewrite them. Assuming the output of those is stable, then probably the hashing updates on the second build (assuming changes were made on first) will get the stable result and cut-off future needs to run. (And if no changes were ultimately made on first build, then hashes fully should resolve the issue.)

[tylerbutler]

Just to state my current thoughts on this PR (why I haven't approved; as discussed in Teams thread):

Thanks for clarifying - I wasn't clear on this point. I prefer to separate out the changes anyway, and once the Biome task changes are merged I could do a prerelease for more folks to test out. So I'll refactor this into two PRs.

That said, I think there's value to hash-based for everything long-term, because it's resilient to incidental touches from e.g. git and is sharable across repos (still dreaming of cloud-cached builds).

[tylerbutler]

Pulled the typetest changes into #21889. We can further discuss it there. I updated the title of this PR to reflect that it is only about the Biome task now.

[jason-ha]

Just to state my current thoughts on this PR (why I haven't approved; as discussed in Teams thread):

Thanks for clarifying - I wasn't clear on this point. I prefer to separate out the changes anyway, and once the Biome task changes are merged I could do a prerelease for more folks to test out. So I'll refactor this into two PRs.

That said, I think there's value to hash-based for everything long-term, because it's resilient to incidental touches from e.g. git and is sharable across repos (still dreaming of cloud-cached builds).

Not really opposed to hash approach - all balance of things anyway.