make native-image creation hermetic to allow remoting via cross-compilation

[cosmicexplorer]

In #6893 we introduce the graal subsystem and use the native-image tool to build scalafmt, which is then executed hermetically. However, because the produced native image is platform-specific, this won't allow for remoting the native-image execution, e.g. if pants is invoked on an OSX machine (producing an OSX native image) and the remote execution environment is Linux (pants would then upload a native image which doesn't work on Linux, causing an error when the remote Linux server attempts to execute the OSX binary). Therefore, in order to make the execution of native image remoteable, we have to make the native image creation remoteable as well.

There was a TODO left in #6893 in graal.py to use v2 process execution for image building, and another TODO in binary_util.py to allow injecting the host_platform to binary tool selection. More concretely:

• Snapshot the graal distribution in graal.py and the tool_classpath in order to use v2 process execution with context.execute_process_synchronously_or_raise().
  • see .hackily_snapshot() in binary_tool.py for an example of snapshotting a binary tool contained outside the buildroot
  • see zinc.py for an example of converting classpath entries into snapshots
  • see the NativeImageExecutor in executor.py for an example of v2 process execution which materializes the output into a directory!
• Allow injecting a host_platform argument into BinaryUtil#select() to resolve a binary tool for a known target platform, and configure native-image building to use Linux when remoting is available.
• (reach goal) Convert all of this into a v2 ruleset instead of a bunch of long methods.
  • This may be blocked on [WIP] Cached local process execution #7171. The approach in [WIP] use graal native-image to create native images of jvm tools for performance increases in certain workflows #6893 is to:
    1. hash the tool_classpath to generate a cache key,
    2. if the native image isn't cached, build the image and materialize the result to a subdirectory of ~/.cache/pants/ (which survives across clean-all)
  • While we can likely rely on the remote execution service to cache native-image builds done remotely, if we want to be able to use native-image locally, we will likely need to implement [WIP] Cached local process execution #7171 first to avoid waiting multiple minutes while the native image is being built.

[cosmicexplorer]

As the current implementation of v2 process execution in pants either remotes zero executions or every execution, we currently don't have to worry about the platform, which will always be the platform of whatever environment the remote execution workers provide. Closing this until it becomes a problem.