[codex] Add rust_test sharding support

[bolinfest]

Summary

Ports the rust_test sharding feature from bazelbuild#3774 into the hermeticbuild fork.

This adds an opt-in experimental_enable_sharding attribute for rust_test. When enabled with the libtest harness, the rule swaps the test executable for a generated wrapper script that:

• touches TEST_SHARD_STATUS_FILE so Bazel recognizes sharding support
• enumerates libtest tests with --list --format terse
• partitions tests with TEST_SHARD_INDEX and TEST_TOTAL_SHARDS
• runs the selected tests with --exact

The wrapper partitions tests deterministically from libtest's listing order. It keeps a zero-based index for every listed test and runs a test in a shard when:

index % TEST_TOTAL_SHARDS == TEST_SHARD_INDEX

For example, with 4 shards, tests at indices 0, 4, 8, ... run in shard 0; indices 1, 5, 9, ... run in shard 1; and so on.

The implementation is adapted for this fork by making rustc_compile_action() return a dict of named providers. Rule implementations convert that dict back to a provider list at their return boundary, while rust_test can look up and replace DefaultInfo directly when sharding is enabled.

Expected Codex Usage

Once Codex consumes this fork update, the plan is to expose a small per-target sharding config in the Codex codex_rust_crate macro rather than sharding every Rust test target. The initial use case is the large codex-core test targets:

codex_rust_crate(
    name = "core",
    crate_name = "codex_core",
    # ...
    test_shard_counts = {
        "core-all-test": 8,
        "core-unit-tests": 8,
    },
)

For generated integration-test targets like core-all-test, the macro can pass both experimental_enable_sharding = True and shard_count = 8 directly to the generated rust_test.

For core-unit-tests, Codex wraps the Rust unit-test binary in a workspace_root_test launcher so tests execute from the repo root. That means the outer workspace_root_test target needs shard_count = 8 so Bazel schedules separate shards, while the inner core-unit-tests-bin rust_test needs experimental_enable_sharding = True so the executable that the launcher runs honors TEST_SHARD_INDEX and TEST_TOTAL_SHARDS.

Validation

• bazel test //test/unit/test_sharding:test_sharding_test_suite
• bazel test --cache_test_results=no --incompatible_check_sharding_support //test/unit/test_sharding:sharded_integration_test
• bazel test //test/unit/test_sharding:test_sharding_test_suite //test/unit/consistent_crate_name:consistent_crate_name_test_suite //test/unit/force_all_deps_direct:force_all_deps_direct_test_suite //test/unit/pipelined_compilation:pipelined_compilation_test_suite
• bazel build //rust/private:bzl_lib
• (cd extensions/prost && bazel build //private:bzl_lib)
• (cd extensions/wasm_bindgen && bazel build //private:bzl_lib)

[tyler-french]

would it be cleaner to have rustc_compile_action() return a dict of named providers instead of a positional list? Then rust_test can look up DefaultInfo / crate_info / test_crate_info directly instead of sniffing provider shape/order.

providers = rustc_compile_action(...)

default_info = providers["DefaultInfo"]
crate_info = providers.get("crate_info") or providers.get("test_crate_info")
if hasattr(crate_info, "crate"):
    crate_info = crate_info.crate

test_binary = crate_info.output
providers["DefaultInfo"] = DefaultInfo(
    files = default_info.files,
    runfiles = default_info.default_runfiles.merge(ctx.runfiles(files = [test_binary])),
    executable = wrapper,
)

return list(providers.values())