CI: run miopen-dbsync (rocjitsu) on gfx90a as advisory #9875

Summary

MIOpen's rocjitsu dbsync (StaticFDBSync) runs on gfx942 and gfx950 only. TheRock's daily gfx90a test runs (Test Artifacts gfx90a, standard) already run Test miopen and Test miopenprovider on gfx90a but schedule no miopen-dbsync, because include_family is ["gfx942", "gfx950"].

Change

• Add "gfx90a" to include_family["linux"] for miopen-dbsync in build_tools/github_actions/fetch_test_configurations.py.
• Declare expect_failure: {"linux": ["gfx90a"]} so the gfx90a job is advisory (xfail) while it is qualified.
• Tests: include_family covers all three families, only gfx90a is advisory, gfx90a is scheduled on the CPU runner when GPU tests are gated.

Branch: users/jlichtne/miopen-dbsync-gfx90a-advisory (PR to follow).

Evidence

rocm-libraries dispatch run https://github.com/ROCm/rocm-libraries/actions/runs/42896619745 with this change pinned: gfx90a @ 104 CU [ PASSED ] 1 test; @ 110 CU fails with 3,293 wrong-workspace mismatches (gfx90a6e, a known issue, rocm-libraries#14519).

Done when

• The daily gfx90a test run shows Test miopen-dbsync (gfx90a) (xfail).
• After the rocm-libraries submodule in TheRock includes the runner change (S1a, below), the log shows StaticFDBSync running at 104 CU, not "skipping dbsync".

Related

• S1a (rocm-libraries runner change): ALMIOPEN-3246 (https://amd-hub.atlassian.net/browse/ALMIOPEN-3246)
• Follow-ups: S2 (build gfx90a on rocm-libraries PRs) and S3 (make gfx90a blocking), tracked as TheRock issues.
• Epic: ALMIOPEN-785