feat(pkgs): add standalone asio 1.38.1

[wellwei]

Summary

• add [email protected] as a standalone header-only package
• expose the upstream include tree and propagate the public standalone/header-only configuration
• retain the Linux -pthread link contract
• add six consumer tests covering core I/O, coroutines, experimental APIs, networking, platform APIs, and the public header surface
• register the Asio consumer project in the repository workspace
• document the package shape, archive evidence, mirror decision, and validation boundary

This PR intentionally excludes the separate native import asio; adapter and optional OpenSSL/wolfSSL, Boost.Context/Regex/Date_Time, and liburing integrations.

README is unchanged.

Upstream verification

• tag: asio-1-38-1, latest numeric Asio tag checked on 2026-07-17
• license: Boost Software License 1.0 (BSL-1.0)
• archive SHA-256: 2827b229972be80cdb14e5497962fa393d1adf036b5869e2b9c99f644daadacc
• two independent downloads produced the same SHA-256
• public include layout: */include/asio.hpp

No CN mirror is declared because no authorized byte-identical mirror asset is available; the descriptor uses the canonical upstream URL.

Local verification

Client: mcpp 0.0.94; local descriptor lint: Lua 5.5.0.

• descriptor syntax, required-field, bare-version, and mirror lint passed
• mcpp xpkg parse pkgs/c/compat.asio.lua passed
• isolated mcpp add compat:[email protected] wrote [dependencies.compat] asio = "1.38.1"
• isolated build downloaded the GLOBAL archive and compiled compat.asio
• cold-state targeted test: 6 passed, 0 failed
• all six consumer compile commands contained ASIO_STANDALONE, ASIO_HEADER_ONLY, and ASIO_DISABLE_BOOST_CONTEXT_FIBER
• git diff --check origin/main...HEAD passed
• README has no diff against origin/main

The active GitHub workflow will run its pinned Lua 5.4 lint and the Linux/macOS/Windows workspace matrix.

[Sunrisepeak]

CI failure analysis: workspace (windows) exit 127

Root cause: the Windows failure was never about the archive encoding — GitHub's tag zip carries the exact same two POSIX symlinks as the tarball (asio-asio-1-38-1/asio/include -> ../include, asio-asio-1-38-1/asio/src -> ../src; verifiable from the zip's external attributes). The job log shows the zip download completing (3.8 MB = full asset size, sha matches) and the process dying immediately after, at the extraction step: xlings extracts zips on Windows via C:\Windows\System32\tar.exe, which cannot materialize those symlink entries on the runner. So 8da9ade (tar.gz → zip) could not fix it.

Why no upstream asset works: upstream publishes no symlink-free 1.38.x artifact — the GitHub repo has no release assets (tags only), and the official SourceForge release channel stops at 1.36.0.

Fix (pushed as 3bb23bd):

• Windows now uses asio-1.38.1-nosymlinks.tar.gz: the upstream tag tarball with only the two symlink entries removed (tar --delete + gzip -n -9). All 1544 regular files verified byte-identical to upstream (source sha256 2827b2…dacc). The consumer include root is unaffected — */include resolves to the real asio-asio-1-38-1/include/, not the symlinks.
• Hosted per ecosystem conventions: GLOBAL at github.com/xlings-res/asio/releases/1.38.1, byte-identical CN at gitcode.com/mcpp-res/asio — both sha256-verified after upload; provenance documented in the xlings-res/asio README.
• Linux/macOS keep the canonical upstream tarball as GLOBAL and gain a byte-identical CN mirror on mcpp-res (addresses the "no authorized CN mirror" note in the PR description).
• Design doc §2/§4 updated accordingly.

Local verification (pinned mcpp 0.0.94): descriptor syntax/mirror/bare-version lints pass, mcpp xpkg parse passes, and a cold mcpp test -p asio on Linux passes 6/6 through the updated descriptor.

Side note for the client repos: an extraction failure surfacing as a bare exit 127 with no error message is a diagnosability wart in the mcpp↔xlings interface path — worth a follow-up issue there, independent of this PR.

[Sunrisepeak]

Follow-up: second Windows root cause found and fixed — CI is now fully green ✅

The symlink-free archive (3bb23bd) fixed the extraction failure; the Windows job then progressed to the next layer: 3 of the 6 asio consumer tests failed at runtime (core/network crashed with 0xC0000409, coroutine exited 1), while the three thread-free tests passed.

Root cause (reproduced exactly under mingw-w64 + wine): asio's thread detection keys off CRT macros (_MT/_REENTRANT/_POSIX_THREADS) that the workspace's llvm-on-Windows toolchain does not define. asio then silently selects null_thread, and every operation needing an internal thread — notably the waitable-timer wait thread behind steady_timer — throws operation_not_supported (10045, thread: asio.system error). steady_timer is exactly the common element of the three failing tests and absent from the three passing ones.

Fix (2208efc): pin ASIO_HAS_THREADS in the default standalone feature. asio only ever tests defined(ASIO_HAS_THREADS), and the POSIX pthread selection still runs beneath it, so this is a no-op on platforms where detection already works.

Verification:

• mingw+wine: the 3 previously-failing tests all pass with the pin (the platform pipe path fails under wine either way — wine limitation, passes on real Windows).
• Linux: cold mcpp test -p asio passes 6/6 with pinned mcpp 0.0.94; ASIO_HAS_THREADS confirmed in every consumer TU's compile command.
• CI run 29586956161: all six jobs green, including workspace (windows).

Design doc §3 updated with the rationale.