Improve --pantsd-invalidation-globs implementation with actual fingerprinting

[kwlzn]

noting Stu's suggestion on #5550

So, I think that this will work. It has some weaknesses related to symlinks I think, but that might be ok for the PYTHONPATH usecase.

Another approach that would be a bit more bulletproof, would be to request a Snapshot for the PathGlobs represented by the option, and to then recompute that Snapshot after every file invalidation event (and it would need to be every event, because the Snapshot does not tell you which symlinks it traversed... it just guarantees that it does), to determine whether the Snapshot's digest had changed. If the digest hadn't changed, this would take a few milliseconds... if it had changed, it would take a bit longer, but not much.

It may not be 100% general though, because if any of the globs represent symlinks outside of the working copy, we'd fail to cover them. Perhaps that requirement is fine?

[cosmicexplorer]

I believe the implementation of this ticket should consider allowing globs outside of the buildroot, possibly allowing some templating with an environment variable, in order to support restarting pantsd if files in the pants repo change when running pants from source, but in a separate repo.

[stuhood]

@cosmicexplorer : That would be ideal, but it is challenging to do with our current implementation of watchman, which can only watch things below the buildroot.

The "watch only what has been globbed" implementation of #4999 might allow for watching arbitrary paths though... cc @illicitonion

[stuhood]

Ah, but even then: if pants is cooperating with the version control system to determine what has changed, it would need a split strategy inside and outside the buildroot. Non-trivial, but desirable.

[blorente]

Closed by #7531