py3-ml-metadata - make py3.13-ml-metadata the default.

[smoser]

See similar changes #36330

[octo-sts]

Gen AI suggestions to solve the build error:

• Detected Error:

ERROR: /home/build/.cache/bazel/_bazel_root/.../external/boringssl/BUILD:133:11: Compiling err_data.c failed: (Exit 1): gcc failed
<command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors

• Error Category: Build Configuration

• Failure Point: Compilation of BoringSSL's err_data.c due to conflicting _FORTIFY_SOURCE definitions

• Root Cause Analysis: The build is failing because _FORTIFY_SOURCE is being defined multiple times with different values. The initial definition from the build system conflicts with the one specified in the gcc command flags.

• Suggested Fix:
Add to the environment section:

environment:
  contents:
    packages:
      - bash
      - bazel-6
      - cmake
      - gcc~13
      - openjdk-11
      - openssl-dev
      - patch
      - py3-supported-build-base-dev
  environment:
    JAVA_HOME: /usr/lib/jvm/java-11-openjdk
    BAZEL_CXXOPTS: -std=c++17:-w
    # Add these lines:
    CFLAGS: "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2"
    CXXFLAGS: "-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2"

• Explanation:
The fix undefines _FORTIFY_SOURCE before redefining it consistently across the build, preventing the redefinition error. This is a common issue when building security-sensitive components like BoringSSL where different build flags might try to set security hardening options differently.

• Additional Notes:

• The -Werror flag is treating warnings as errors, making this a hard failure
• BoringSSL is particularly sensitive to build flags due to its security requirements
• Similar issues have been seen in other packages using BoringSSL as a dependency

• References:

• https://github.com/google/boringssl/issues/464
• https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-_005fFORTIFY_005fSOURCE