Refactor toolchain feature modeling to shared explicit `cc_feature` composition

[nradakovic]

What

Refactor the Bazel C++ toolchain configuration after the no_legacy_features migration so that explicitly defined toolchain features are composed from shared reusable cc_feature definitions instead of being duplicated across multiple platform-specific templates.

The target architecture is:

• a shared library of reusable explicit cc_feature definitions for common toolchain behavior
• a Linux-specific composition layer for Linux-only required behavior
• a QNX-specific composition layer for QNX-only required behavior
• thin platform toolchain templates that assemble the required feature bundles and retain ownership of platform/runtime/toolchain identity concerns

This epic focuses on reducing duplication and improving maintainability of the explicit feature model that already exists after the legacy-feature migration.

Why

Once the toolchain no longer depends on Bazel legacy features, the next maintenance problem becomes structural duplication.

Linux and QNX toolchain configurations currently contain overlapping feature logic, but not all of that logic should remain duplicated long term. At the same time, required built-in behavior should not be pushed into optional consumer configuration just to achieve reuse.

The desired outcome is a composition model where:

• shared required behavior is defined once
• platform-specific required behavior remains owned by the toolchain
• optional consumer extensions continue to use injected cc_feature definitions
• Linux and QNX toolchain implementations become thinner and easier to evolve

Goals

• Reduce duplication between Linux and QNX toolchain feature definitions.
• Extract reusable common explicit cc_feature definitions.
• Preserve platform-specific behavior where Linux and QNX genuinely differ.
• Keep required toolchain behavior owned by the toolchain rather than shifting it into optional consumer configuration.
• Improve maintainability, readability, and testability of the explicit feature model.
• Create a structure that could support a single template later if the remaining differences become purely data-driven.

Non-Goals

• Migrating away from Bazel legacy features as part of this Epic.
• Reopening the decision to make the toolchain explicit.
• Treating all required built-in toolchain behavior as externally injected features.
• Forcing Linux and QNX into a single template immediately.
• Expanding platform support beyond currently supported scenarios.

Scope

This epic includes:

• reviewing the explicit feature model created after the no_legacy_features migration
• identifying shared vs platform-specific required feature behavior
• extracting reusable common cc_feature definitions
• introducing platform-specific feature bundles where needed
• updating Linux and QNX toolchain assembly to compose features from shared and platform-specific sources
• validating supported configurations after the refactor
• documenting the resulting composition model for maintainers and consumers

This epic does not include the original migration away from Bazel legacy features.

Proposed Architecture

Shared/common layer

Own reusable explicit feature definitions that are common across toolchain families, for example:

• compile mode features such as dbg and opt
• common compile and link flag features
• warning model features
• common coverage-related features where behavior is truly shared
• shared feature ordering and composition helpers
• shared conversion of injected FeatureInfo-based features

Linux-specific layer

Own Linux-only required behavior, for example:

• sysroot-related feature handling
• Linux runtime/linker assumptions
• Linux-specific builtin include modeling
• Linux-specific required compiler/runtime feature behavior

QNX-specific layer

Own QNX-only required behavior, for example:

• license and environment setup features
• dependency-file behavior
• runtime library search directory behavior
• QNX-specific include and runtime semantics
• QNX-specific required compiler/runtime feature behavior

Toolchain assembly layer

Each platform toolchain template should remain responsible for:

• action configs
• tool selection and tool paths
• compiler identity and ABI metadata
• platform/runtime attributes
• assembling common features, platform features, and optional consumer-injected features
• returning the final CcToolchainConfigInfo

Deliverables

• A reviewed and documented classification of shared vs platform-specific explicit features.
• A shared feature composition module for common required features.
• A Linux-specific feature composition module.
• A QNX-specific feature composition module.
• Refactored platform toolchain templates that assemble explicit feature bundles.
• Validation updates covering supported configurations and required feature behavior.
• Consumer and maintainer documentation describing the feature composition model and extension points.

Acceptance Criteria

• Explicit feature logic that is genuinely common is no longer duplicated across Linux and QNX implementations.
• Required platform behavior remains owned by the toolchain implementation and is not incorrectly shifted into optional external feature injection.
• Linux and QNX toolchain templates become thinner and primarily act as assembly layers.
• Consumer-injected features remain supported for optional extensions and policy-specific behavior.
• All supported build and validation configurations continue to work without regressions after the refactor.
• The resulting structure makes it clear which behavior is common, which is platform-specific, and which is consumer-extensible.

Suggested Work Breakdown

• Review the explicit feature model introduced by the no_legacy_features migration.
• Classify explicit features into common, Linux-specific, QNX-specific, and consumer-extensible groups.
• Define the shared/common feature set.
• Define Linux-only required feature composition.
• Define QNX-only required feature composition.
• Refactor toolchain templates to assemble explicit feature bundles.
• Add or update validation for required feature behavior and supported configurations.
• Document the architecture and composition model.

Risks / Open Questions

• Some behaviors that appear common may still differ subtly between Linux and QNX and should not be unified prematurely.
• Feature ordering may become more important after extraction and must remain deterministic.
• Moving required behavior too far away from the toolchain assembly layer could make the toolchain contract harder to understand.
• A single unified template may or may not be the correct end state; that decision should be made after common extraction, not before.

Definition of Done

This epic is complete when:

• the explicit feature model introduced after the legacy-feature migration has been refactored into shared and platform-specific composition layers
• shared features are factored into reusable common definitions
• Linux and QNX retain thin platform-specific assembly where needed
• supported configurations pass validation without regressions
• the repository documents how required, platform-specific, and consumer-injected features are composed