Ship the thread pool as its own library so a process has one pool

[shoumikhin]

The thread pool that spreads CPU work across cores is meant to be a
process-wide singleton, but it is held in a function-local static inside a
static library, so every component that links it gets a private copy. The
wheel ships two of them today: the pybindings extension and the training
extension each define get_threadpool. Loading both into one interpreter
gives the process two pools, and because each sizes itself to the machine's
core count independently, they oversubscribe the CPU and contend with each
other.

Build the thread pool as a shared library for the wheel and let both
extensions resolve it, so there is one pool per process again. cpuinfo and
pthreadpool are forced static, so they are bundled inside this library
rather than left for each consumer to supply, and the runtime is resolved
from the shared runtime instead of embedding a second copy of the core.

This is gated on the existing EXECUTORCH_BUILD_SHARED option, so only the
Linux wheel changes; iOS, Android, and embedded builds keep linking the
static library exactly as before.

Test plan:

The wheel smoke test now asserts that exactly one shipped library defines
the thread pool accessor, alongside the existing single-backend-registry
assertion, so a future change that reintroduces a second pool fails in CI
rather than silently degrading performance. The new assertion was confirmed
to fail against a wheel built before this change, where it correctly reports
the two definers by name.

Built the wheel from a clean checkout and verified against a fresh virtual
environment with a normal dependency-resolving install:

• nm -DC across every shipped shared object shows exactly one definition of
  get_threadpool, in the new library; the extensions import it rather than
  defining their own.
• readelf -d shows the pybindings extension records the versioned thread
  pool library in DT_NEEDED, with a relocatable RUNPATH so it resolves the
  runtime as a sibling without LD_LIBRARY_PATH.
• The single-backend-registry assertion still holds with the new library
  loaded.
• import executorch, the registered backend list, and .pte execution
  through the Python bindings are unchanged, with outputs matching eager
  PyTorch.
• With EXECUTORCH_BUILD_SHARED off, the thread pool is still a static
  library and no new shared object is produced, so every build that does not
  opt in is unaffected.

[shoumikhin]

Stack from ghstack (oldest at bottom):

• Ship the CUDA delegate as its own library #21531
• Ship the XNNPACK delegate as its own library #21526
• Ship the merged CPU kernels as their own library #21524
• -> Ship the thread pool as its own library so a process has one pool #21522
• Ship a linkable shared runtime and make the Python bindings use it #21514

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21522

• 📄 Preview Python docs built from this PR

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

❌ 5 Cancelled Jobs, 7 Pending, 1 Unrelated Failure, 3 Unclassified Failures

As of commit e058bf3 with merge base d632341 ():

UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:

• Build Aarch64 Linux Wheels / generate-matrix / generate (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
• Build macOS Wheels / generate-matrix / generate (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
• trunk (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)

CANCELLED JOBS - The following jobs were cancelled. Please retry:

• Test WebGPU Backend / test-webgpu / package-golden-artifacts (gh)
• Test WebGPU Backend / test-webgpu / test-backend-linux (webgpu, models) / linux-job (gh)
• Test WebGPU Backend / test-webgpu / test-backend-linux (webgpu, operators) / linux-job (gh)
• Windows MSVC Build / CI run decision / decide (gh)
• Windows MSVC Build / Get changed files / get-changed-files (gh)

FLAKY - The following job failed but was likely due to flakiness present on trunk:

• pull / unittest-editable / windows / windows-job (gh) (detected as infra flaky with no log or failing log classifier)

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