Check replicas are there, when meta_p.wiki says so

[agoujot]

In a nutshell: look up in information_schema if we actually have any tables for those projects.

Bug: T322466

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.66%. Comparing base (4b8eb28) to head (f2d2757).
⚠️ Report is 185 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #568      +/-   ##
============================================
- Coverage     71.30%   69.66%   -1.65%     
- Complexity     1275     1323      +48     
============================================
  Files            46       46              
  Lines          3792     3976     +184     
============================================
+ Hits           2704     2770      +66     
- Misses         1088     1206     +118     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[agoujot]

Just realised we do in fact have access to information_schema.tables.

[agoujot]

I have a working cleaner solution with information_schema. For speed concerns (notably EC calling a lot of ->exists() for different projects), these checks should be run in one batch; which can be easily done knowing the list of projects to check.
For tools that can only use one project (most) it's straightforward.
EC pulls all of its multi-project capacity straight from GC.
GC can normally be accomodated by adding a method to Project.php to load the existence of all projects, similar to how getAll works.