Generate a test dependencies file to support unit tests in entitlements

[jdconrad]

Generates a test file with the following information and format:

{
    "component": "<component name>",
    "locations": [
        {
            "representative_class": <class name with package>,
            "module": "<module name>"
        },
        ...
    ]
}

For painless:

{
    "component": "lang-painless",
    "locations": [
        {
            "representative_class": "org/objectweb/asm/tree/analysis/Analyzer.class",
            "module": "org.objectweb.asm.tree.analysis"
        },
        ...
    ]
}

Then it copies the following files into the jar for consumption by unit tests:

* META-INF/test-build-info.json
* META-INF/es-plugins/<plugin name>/plugin-descriptor.properties
* META-INF/es-plugins/<plugin name>/entitlement-policy.yaml

For server, the files in the jar become the following:

* META-INF/test-build-info.json

This should provide enough information for BootstrapForTesting to be able to build a mapping of caller class to policy file using the class file to look up the jar or directory within the class path and then associating that with it's specified module and finally using the specified module to look up the appropriate entitlement policy. caller class -> specified module -> entitlement policy

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[prdoyle]

We could reduce redundancy by mapping just package names to modules, instead of every individual class. That should make the file much smaller.

[prdoyle]

Jack pointed out that this already has just one entry per jar/directory.

In that case, I wonder if the structure should include that jar/directory info, if only for troubleshooting. Even if we don't need it to make our use case work, it could be easier for humans if the jar/directory is present in the file.

Update: the reason for using the representative class instead of the jar/directory is because its location could be different at runtime depending on which tests are running. If we're not careful, that info could be not just useless, but misleading.

[jdconrad]

@ryan @ldematte @mark-vieira Patrick and I believe this is ready for another round of review. Thanks!

[mark-vieira]

One additional clarification but otherwise LGTM.

[rjernst]

LGTM

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	8.19