Unable to use stamp information in `java_binary`'s MANIFEST.MF

Start with the java_binary deploy_manifest_lines attribute and reproduce the issue using the .bazelrc and BUILD.bazel examples. Inspect how workspace status is exposed through bazel-out/stable-status.txt and bazel-out/volatile-status.txt, then define a supported way for custom values to reach META-INF/MANIFEST.MF and verify the result in the generated test_deploy.jar.

As far as I can tell, it currently isn't possible to use the output from --workspace_status_command in java_* rules. Specifically, it seems like a fairly common use-case (and coincidentally, what I'm currently trying to do 😉) would be to include some form of build information (revision / build date / whatever) in the MANIFEST.MF of a .jar file.

Expected behaviour: able to --stamp a java_binary with custom variables
Actual behaviour: unable to pass through any custom variables to deploy_manifest_lines
Steps to reproduce:

As a fairly trivial reproduction:

# .bazelrc
common --stamp --workspace_status_command=/usr/bin/true --embed_label="Hello"

# BUILD.bazel
java_binary(name = "test", ..., deploy_manifest_lines = [ "Custom-Label: {{BUILD_EMBED_LABEL}}" ])

Running bazel build :test_deploy.jar && unzip -p bazel-bin/test_deploy.jar META-INF/MANIFEST.MF outputs:

...
Custom-Label: {{BUILD_EMBED_LABEL}}
...

rather than the desired:

...
Custom-Label: Hello
...

Extra information

I'm not 100% sure if this has changed in newer versions of rules_java (having a quick glance at the source, it seemed not?) but at least as of v7.x the attribute for deploy_manifest_lines only accepts a list of strings, and states:

The contents of this attribute are not subject to "Make variable" substitution.

It seems like there are maybe two related problems*, one is specific to rules_java and the other is a more general Bazel thing:

1. java_binary only accepts fixed strings for deploy_manifest_lines
2. Bazel does not provide convenient access to workspace status vars in macros or custom rules.

From what I've seen in some other places (e.g. rules_oci) there's no good solution to (2), so the pattern seems to be to allow providing a single file to use, and then having a command that generates that file by also reading from the bazel-out/stable-status.txt and bazel-out/volatile-status.txt files, e.g.

# BUILD.bazel
java_manifest(name = "manifest", lines = {"Custom-Label": "{{BUILD_EMBED_LABEL}}")
java_binary(name = "test", ..., deploy_manifest_lines = ":manifest")

* I imagine some people will argue this is a feature, but it doesn't feel like it from here!

If it's possible to do it without generating an intermediate file, that would be even better, but I suspect that won't be the case (at least without some major work to Bazel itself...)!