Add options to fast-filedeps to bring it close to parity with V1 filedeps

[Eric-Arellano]

Problem

We want to finish replacing V1 filedeps with V2 fast-filedeps. Keeping both goals around gives us added complexity, e.g. more time in CI for tests.

To finish the replacement, fast-filedeps must first get support for --absolute and --globs.

Solution

Add support for --absolute and --globs.

Also, fix and refactor the unit tests, which were skipped in #6880 and never restored. Update the integration test to mirror the V1 test.

We can't yet actually drop the V1 goal yet due to two features that need to be implemented for full feature parity: 1) handling scala_library's java_sources and 2) supporting jvm_apps. This PR adds failing unit tests for both those cases. Once those tests can be un-skipped, then we can drop V1.

[Eric-Arellano]

Was able to finish the port thanks to @stuhood's suggestion!

However, I'm not confident merging this until we can confirm that both of these special JVM related cases are handled:

pants/src/python/pants/backend/project_info/tasks/filedeps.py

Lines 35 to 41 in fe6a2d3

	# TODO(John Sirois): This hacks around ScalaLibraries' psuedo-deps on JavaLibraries. We've
	# already tried to tuck away this hack by subclassing closure() in ScalaLibrary - but in this
	# case that's not enough when a ScalaLibrary with java_sources is an interior node of the
	# active context graph. This awkwardness should be eliminated when ScalaLibrary can point
	# to a java source set as part of its 1st class sources.
	if isinstance(concrete_target, ScalaLibrary):
	concrete_targets.update(concrete_target.java_sources)

pants/src/python/pants/backend/project_info/tasks/filedeps.py

Lines 57 to 63 in fe6a2d3

	# TODO(John Sirois): BundlePayload should expose its sources in a way uniform to
	# SourcesPayload to allow this special-casing to go away.
	if isinstance(target, JvmApp) and not output_globs:
	for bundle in target.bundles:
	files.update(
	bundle.filemap.keys() if self.get_options().absolute else bundle.relative_filemap.keys()
	)

I need to figure out how to add tests for these situations.

[cattibrie]

It would be nice to update examples to have at least two files of the same extension (like .scala) in one directory to test that --globe option works for more than one file.

[cattibrie]

@Eric-Arellano Thanks for this PR! Really like type annotations and how tests look now!

[stuhood]

Thank you!

[stuhood]

So... one development since this was opened is the Workspace type.

I think that the semantics of the BuildRoot type (exposes some information) are sufficiently different from the Workspace type (implies mutable access) that having them separate could be reasonable. I could also see merging them, and exposing Workspace.root or something. "Relatively small single purpose things to DI" is a thing... but the BuildRoot is almost too specific a thing, and would always have a subset of the fields of Workspace.

Fine either way though.

[stuhood]

cc @gshuflin

[Eric-Arellano]

@stuhood could you please re-review? We can't drop V1 yet because we don't properly handle two JVM related use cases :/ I updated the PR description and added skipped failing unit tests.

This does at least bring us much closer to dropping the V1 goal!