[Bug] MySQL datasource is not connectivity-checked on add/save; invalid configs save successfully

Question and Steps to reproduce

When adding a MySQL datasource and clicking "test connectivity & save" (not force-save), the save succeeds even if the host/port/user/password are wrong — unlike Prometheus or ClickHouse, which block the save when the connection check fails.

Steps to reproduce:

Data source management → add datasource → MySQL Enter an unreachable address (or wrong credentials), click "test connectivity & save" Save succeeds; the datasource appears in the list as enabled Actual behavior: no real connection attempt is made at save time. Comparison with the other types:

Prometheus / Loki / TDEngine / IoTDB: DatasourceCheck performs a real HTTP request and blocks the save on failure; ClickHouse: InitCli + SHOW DATABASES, blocks the save on failure; MySQL: only structural validation runs — models.Datasource.Verify checks the name and runs FE2DB(); the mysql plugin's Validate only checks that addr/user are non-empty. No dial happens. The real connection is deferred to the dscache sync, where InitClient (NewConn → sqlDB.Ping() in dskit/sqlbase/base.go) runs asynchronously; a failure only logs an error and evicts the entry from the in-memory cache, leaving the DB row untouched. Impact: a broken MySQL datasource can be saved and only fails later during queries/alerting; "saved" does not imply "reachable".

Expected behavior: like ClickHouse, run a real connectivity test at save time for MySQL (open connection + SHOW DATABASES), block the save and return the error on failure; "force save" (force_save) should still skip the test.

Relevant code:

center/router/router_datasource.go → datasourceUpsert: PROMETHEUS/LOKI/TDENGINE/IOTDB → DatasourceCheck; CLICKHOUSE → InitCli+ShowDatabases; ELASTICSEARCH → version fetch; MYSQL has no such branch dskit/mysql/mysql.go NewConn → dskit/sqlbase/base.go NewDB (ends with a real sqlDB.Ping()) dscache/cache.go Put → InitClient failures are only logged and the entry evicted from cache

Relevant logs and configurations

It's a repo bug, not an environment issue — a known improvement.  No crash; n9e logs a warning only at the later dscache sync, e.g.:
init plugin:mysql <id> ... client fail: ... — the datasource is saved but missing from the in-memory cache.

Version

Nightingale version: about page / ./n9e -v OS: regression exists unconditionally; verified on Windows Arch: amd64 Frontend (n9e/fe) version: 9.0