Adjust when we build for code coverage when it isn't enabled (#3257)

Fixes #3255 (partially)

For builds where code coverage is not enabled in the scheme's test
action, do not build with coverage. Should reduce thrash in index builds
and address a regression in the cache performance of Xcode builds that
hadn't opted into this feature.

Note: this does not fix the issue for build-for-running builds of tests,
as we have no clear-cut way of differentiating between build-for-running
and build-for-testing in the BazelDependencies run script phase. Open to
other ideas, since this is based on undocumented xcodebuild behavior and
is not super-nice.

Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>

Author: aaronsky

xcodeproj/internal/templates/generate_bazel_dependencies.sh

@@ -121,7 +121,14 @@ if [ "$ACTION" == "indexbuild" ]; then
   apply_sanitizers=0
 elif [ "${ENABLE_PREVIEWS:-}" == "YES" ]; then
   readonly config="${BAZEL_CONFIG}_swiftuipreviews"
-elif [ "${ENABLE_CODE_COVERAGE:-}" == "YES" ]; then
+elif [ "${CLANG_COVERAGE_MAPPING:-}" == YES ]; then
+  # Code coverage build
+  #
+  # CLANG_COVERAGE_MAPPING is set to YES when the active scheme's test action has code coverage enabled. It is configured
+  # irrespective of the value of ENABLE_CODE_COVERAGE, and of whether the current build action is for testing or not.
+  #
+  # We would rather use ENABLE_CODE_COVERAGE here, but the value of that setting is often YES even when code coverage is not
+  # enabled in the active scheme.
   readonly config="${BAZEL_CONFIG}_coverage"
 
   echo "warning: Code coverage is enabled. In order to maintain compatibility with Xcode, the instrumented build is not hermetic. Remote cache performance will be affected." >&2