Add exec_group_compatible_with attribute

[fmeum]

This change implements the Per-target execution platform constraints for exec groups proposal by adding the exec_group_compatible_with attribute. It differs from the proposal in its accepted from in two ways:

• During the implementation of the proposal, it was discovered that the test exec group always inherits toolchain requirements and constraints from the default exec group. This behavior makes it impossible to apply additional constraints to the default exec group via exec_compatible_with without also applying them to the test exec group. This preexisting behavior has mostly undesirable consequences: In a multi- or cross-platform build, where exec constraints matter, tests actions and build actions are unlikely to ever be bound to the same toolchain requirements as tests actions don't consume toolchains directly and their intended execution platform is usually closer to the target platform.
• The proposal also includes the plan to have exec_compatible_with apply to all non-test exec groups and renaming the default execution group to default. This PR does not implement this change as it makes it easier to accidentally apply execution constraints too broadly as can currently happen with tags with --incompatible_allow_tags_propagation (e.g. tags = ["no-remote"] on a test also applies this restriction to the action compiling the test). More fine-grained primitives for adding constraints pose less of a risk.

Fixes #23202
Fixes #23802

RELNOTES: The new exec_group_compatible_with attribute on all rules accepts a dictionary mapping exec group names to lists of additional constraints to request from the exec group's execution platform.

RELNOTES[INC]: Constraints and toolchain requirements added to the default exec group, for example via the toolchains parameter of the rule function or the exec_compatible_with attribute on all rules, no longer apply to the test exec group, which contains the test action on test rules. Instead, use exec_group_compatible_with to apply constraints and/or define an explicit test exec group with toolchain requirements on test rules that require it.

[keith]

on this reproducer: #23202 (comment) w/ this change (and the exec_properties one) I get this crash:

FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node '' (requested by nodes ':all, excludedSubdirs=[], filteringPolicy=com.google.devtools.build.lib.pkgcache.FilteringPolicies$FilterManual@7dab797e')
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:551)
        at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:435)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1577)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1489)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2071)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2033)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
Caused by: net.starlark.java.eval.Starlark$UncheckedEvalException: InvalidStarlarkValueException thrown during Starlark evaluation (an initializer)
        at <starlark>.cc_test(<builtin>:0)
        at <starlark>.<toplevel>(/tmp/repro/BUILD.bazel:30)
Caused by: net.starlark.java.eval.Starlark$InvalidStarlarkValueException: invalid Starlark value: class java.util.ArrayList
        at net.starlark.java.eval.Starlark.checkValid(Starlark.java:136)
        at net.starlark.java.eval.Dict.lambda$copyOf$0(Dict.java:454)
        at com.google.common.collect.SingletonImmutableBiMap.forEach(SingletonImmutableBiMap.java:70)
        at net.starlark.java.eval.Dict.copyOf(Dict.java:451)
        at net.starlark.java.eval.Starlark.fromJava(Starlark.java:217)
        at com.google.devtools.build.lib.packages.Attribute$StarlarkComputedDefaultTemplate.computeValue(Attribute.java:1471)
        at com.google.devtools.build.lib.packages.Attribute$StarlarkComputedDefaultTemplate$1.compute(Attribute.java:1425)
        at com.google.devtools.build.lib.packages.Attribute$ComputationStrategy.computeValuesForAllCombinations(Attribute.java:1228)
        at com.google.devtools.build.lib.packages.Attribute$StarlarkComputedDefaultTemplate.computePossibleValues(Attribute.java:1446)
        at com.google.devtools.build.lib.packages.RuleClass.populateDefaultRuleAttributeValues(RuleClass.java:2438)
        at com.google.devtools.build.lib.packages.RuleClass.populateRuleAttributeValues(RuleClass.java:2208)
        at com.google.devtools.build.lib.packages.RuleClass.createRule(RuleClass.java:2158)
        at com.google.devtools.build.lib.packages.RuleFactory.createRule(RuleFactory.java:106)
        at com.google.devtools.build.lib.packages.RuleFactory.createAndAddRule(RuleFactory.java:141)
        at com.google.devtools.build.lib.analysis.starlark.StarlarkRuleClassFunctions$StarlarkRuleFunction.call(StarlarkRuleClassFunctions.java:1754)
        at net.starlark.java.eval.StarlarkCallable.fastcall(StarlarkCallable.java:87)
        at net.starlark.java.eval.Starlark.fastcall(Starlark.java:804)
        at net.starlark.java.eval.Eval.evalFastcall(Eval.java:821)
        at net.starlark.java.eval.Eval.evalCall(Eval.java:678)
        at net.starlark.java.eval.Eval.eval(Eval.java:547)
        at net.starlark.java.eval.Eval.exec(Eval.java:288)
        at net.starlark.java.eval.Eval.execStatements(Eval.java:83)
        at net.starlark.java.eval.Eval.execFunctionBody(Eval.java:67)
        at net.starlark.java.eval.StarlarkFunction.callWithArguments(StarlarkFunction.java:225)
        at net.starlark.java.eval.StarlarkFunction.positionalOnlyCall(StarlarkFunction.java:209)
        at net.starlark.java.eval.Starlark.positionalOnlyCall(Starlark.java:872)
        at net.starlark.java.eval.Starlark.execFileProgram(Starlark.java:1195)
        at com.google.devtools.build.lib.packages.PackageFactory.executeBuildFileImpl(PackageFactory.java:416)
        at com.google.devtools.build.lib.packages.PackageFactory.executeBuildFile(PackageFactory.java:377)
        at com.google.devtools.build.lib.skyframe.PackageFunction.loadPackage(PackageFunction.java:1188)
        at com.google.devtools.build.lib.skyframe.PackageFunction.compute(PackageFunction.java:539)
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:471)
        at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:435)
        at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1577)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1489)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2071)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2033)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

i looked into this a bit last week and I believe it's because this function

bazel/src/main/java/net/starlark/java/eval/Starlark.java

Line 217 in 19ecfc4

return Dict.copyOf(mutability, (Map<?, ?>) x);

needs some sort of "deep copy" in this case, but I couldn't figure that out so I can't say for sure

[keith]

verified on the latest commits here it works with this repro case now!

[fmeum]

Currently stacked on #24979

[fmeum]

This is a drive-by improvement to avoid creating and retaining an entry set.

[katre]

I've reviewed the documentation changes (great!) and the non-test code changes. I'd like to ask you to split those further, to make import and history easier to read, but overall everything looks good.

I'll review the test changes once those are split out.

[fmeum]

I split up all changes above #24979 into five commits that can be reviewed and merged independently (in order).

Since stacked CLs are much easier than stacking PRs on GitHub, could you convert the commits into separate CLs during import? If not, let me know and I can send five separate stacked PRs.

[katre]

Sounds good, I'll try to import separately.

I agree that Github's workflow for stacked PRs is terrible.

[katre]

One small nit, let me know if you want to fix it or if I should handle on import.

[katre]

Once tests pass I'll start importing these: @gregestren and @fweikert, if you have any comments please add them.

[meteorcloudy]

Looks like this change is breaking Stardoc in downstream pipeline:
Downstream: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/4444#0194cf26-544e-4366-a0c3-32ff33768f6d
Bisect: https://buildkite.com/bazel/culprit-finder/builds/11817#0194d076-4d8f-40b3-b2e3-20dc70745043

[fmeum]

I can work on a fix for Stardoc @tetromino

[fmeum]

I sent bazelbuild/stardoc#279