Let aquery print effective environment for all CommandActions

[fmeum]

Instead of printing the fixed part of the ActionEnvironment of all SpawnActions, aquery now prints the effective environment resolved against an empty client environment of all AbstractActions that implement CommandAction.

For SpawnActions, this should not result in any observable change, but C++ actions, which only override AbstractAction#getEffectiveEnvironment, now have their fixed environments (e.g. toolchain env vars such as INCLUDE with MSVC) emitted.

Work towards #12852

[fmeum]

@meisterT Could you review this PR?

@cpsauer Could you check that this fixes the aquery problem? I don't think it would affect extra actions, but then I also know almost nothing about them. Also don't expect DEVELOPER_DIR to show up as that is not available on the action but only on the spawn level.

[cpsauer]

Thanks for diving in @fmeum! Looks to be a good improvement to me.

[I don't have much experience in this part of the codebase, but radiating ideas: Might it make sense to pass through the actual client environment if it might influence the execution environment? Certainly that shouldn't block merging or anything, but it strikes me that people probably run this trying to understand how the build maps to commands on their specific machine/environment. That's true of the tool I maintain that uses this at least.]

[fmeum]

@cpsauer Making the output of aquery dependent on the host environment is a kind of change that definitely needs more thought. It's possible that adding new fields for inherited variables is better - any kind of external tooling consuming aquery output could just add the values of the environment itself, but the output would remain host-independent.

The Xcode variables receive special handling by Bazel that is more or less equivalent to (but more efficient than) running xcode-locator as part of the action. Since with this change all environment variables that go into xcode-locator are available from aquery output, external tooling could run xcode-locator itself to determine the missing values.

[cpsauer]

Seems like it already is--inferred platform, environment specifying compiler, etc., right?--but you guys are certainly the experts.

Definitely don't want this side discussion to block this improvement, though.

[fmeum]

@bazel-io flag

[fmeum]

Seems like it already is--inferred platform, environment specifying compiler, etc., right?--but you guys are certainly the experts.

Definitely don't want this side discussion to block this improvement, though.

All these things are deterministic functions of the outputs of repository rules, which you can either circumvent by specifying values for command-line flags such --platforms or at least enumerate and thus get into a hermetic state with just a bit of work. Depending on the entire client environment would make that next to impossible.

[cpsauer]

Sweet. Thanks again, guys.

[ShreeM01]

@bazel-io fork 6.1.0

[ShreeM01]

Hi @fmeum! We are trying to cherry-pick the changes to release 6.1.0. But pre-submits checks are failing ([https://github.com//pull/17274]) . So could you please help us in cherry-picking this changes to release 6.1.0?