Update the Gazelle Java plugin to handle java_maven_install_file directives in nested directories

[jeffmace]

Create a maven.Resolver for each instance of java_maven_install_file and use that resolver for all files under that directory. There aren't any changes to the default behavior; but nested java_maven_install_file declarations will now work as expected.

Background
The Gazelle plugin parses java_maven_install_file directives in nested directories but doesn't use the file when resolving dependencies. This is a problem for projects that use different Maven repositories for different parts of the repository. The top-level maven_install.json file may have incomplete or extra dependencies than the one configured for the lower level directory.

Testing
The unit tests have been updated to reflect the new interface. Integration tests have been added to confirm the updated behavior for an invalid maven_install.json file.

[jeffmace]

@shs96c - Does this look like a reasonable bug fix to bring in?

[shs96c]

Apologies for the slow review. Looking now.

[shs96c]

I've a feeling that this isn't going to work when the lock file isn't in the repo root. That's because MavenInfoFile() also looks for the lock file against the repo root and not the directory where the directive was discovered. I think you'll need to store the full path to the lock file and not just the path given by the directive.

[shs96c]

How come this file is the v1 lock file format and not the v2 format?

[shs96c]

This should also be a v2 lock file

[jeffmace]

I updated one of the lock files to v2 to show that it doesn't affect the behavior. I can update the other lock file but it isn't critical since the plugin should continue to support v1 lock files.

What do you think of an update to run //:pin when UPDATE_SNAPSHOTS=true is set? That would make it easier to update the lock files as needed.

[jeffmace]

I've a feeling that this isn't going to work when the lock file isn't in the repo root. That's because MavenInfoFile() also looks for the lock file against the repo root and not the directory where the directive was discovered. I think you'll need to store the full path to the lock file and not just the path given by the directive.

I've updated the test case to show that providing the full path to the lock file will work. I believe this matches the current behavior because there aren't any changes to maven.NewResolver.