[Performance] Enable worker metadata for automatic parallel envs

[vmoens]

Summary

• automatically enable worker-originated metadata when environment convenience constructors create a ParallelEnv from num_workers
• cover Gym, DMControl, Brax, Habitat, LIBERO, Genesis, MJLab, MuJoCo Playground, and process-based custom MuJoCo environments
• retain parent-side metadata for known heterogeneous LIBERO schemas and Habitat device assignments
• document the automatic behavior and extend the existing integration tests

Motivation

metadata_from_workers=True was introduced in #4028 to avoid constructing temporary environments in the parent process. Convenience constructors such as GymEnv(..., num_workers=N) synthesized a ParallelEnv without enabling that mode, so they still paid the parent-side construction cost unless users built the ParallelEnv manually.

This follow-up makes the optimized path automatic when the generated workers have compatible tensor schemas. Gym's native num_envs vectorization remains unchanged.

User impact

Automatically generated process-based environments now start their workers during construction and use pipe-based communication (use_buffers=False), as required by worker-originated metadata. Expensive simulator environments are no longer instantiated solely for metadata in the parent process.

Validation

• pytest -q test/envs/test_parallel.py -k metadata_from_workers
• focused num_workers tests across Gym, LIBERO, Habitat, Genesis, MJLab, custom MuJoCo, Brax, DMControl, and MuJoCo Playground
• pre-commit hooks for all changed files (ufmt run directly from the cached Python 3.11 hook environment)

Local result: 16 passed. Seven optional-dependency cases were collected and skipped because those dependencies or CUDA were unavailable locally; the ci/optdeps label requests their full CI coverage.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/rl/4093

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

✅ You can merge normally! (6 Unrelated Failures)

As of commit e5726f0 with merge base 4169419 ():

FLAKY - The following jobs failed but were likely due to flakiness present on trunk:

• Libs Tests on Linux / unittests-chess (3.10, 12.8) / linux-job (gh) (matched linux rule in flaky-rules.json)
  E: Failed to fetch https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/Packages.gz File has unexpected size (2900818 != 2899113). Mirror sync in progress? [IP: 23.39.174.134 443]
• Libs Tests on Linux / unittests-libero (3.10, 12.8) / linux-job (gh) (matched linux rule in flaky-rules.json)
  E: Failed to fetch https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/Packages.gz File has unexpected size (2900818 != 2899113). Mirror sync in progress? [IP: 23.48.203.204 443]
• Libs Tests on Linux / unittests-meltingpot / linux-job (gh) (matched linux rule in flaky-rules.json)
  E: Failed to fetch https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/Packages.gz File has unexpected size (2900818 != 2899113). Mirror sync in progress? [IP: 23.48.203.204 443]
• Libs Tests on Linux / unittests-open_spiel (3.10, 12.8) / linux-job (gh) (matched linux rule in flaky-rules.json)
  E: Failed to fetch https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/Packages.gz File has unexpected size (2900818 != 2899113). Mirror sync in progress? [IP: 23.48.203.204 443]

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• Unit-tests on Linux / tests-cpu (3.10, bulk) / linux-job (gh) (trunk failure)
  test/rb/test_storages.py::TestStorages::test__rand_given_ndim_recompile
• Unit-tests on Linux / tests-cpu (3.13, bulk) / linux-job (gh) (trunk failure)
  test/rb/test_storages.py::TestStorages::test__rand_given_ndim_recompile

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[vmoens]

@ParamThakkar123 @itwasabhi, would you be able to review this follow-up? It automatically enables metadata_from_workers=True for the num_workers constructor paths. Param, you implemented constructor-level parallelization across Gym, DMControl, Brax, Habitat, and Genesis; Abhishek, you introduced the MuJoCo Playground integration and its parallel constructor path. Feedback on eager worker startup, use_buffers=False, and the heterogeneous-schema fallback would be especially valuable.

[ParamThakkar123]

Sure @vmoens, I will review this one