fix(doris): drop MySQL routine and event probes from the schema dump - #21467

BYT-10211.

The StarRocks/Doris driver was copied from the MySQL driver, and its Dump still runs SHOW FUNCTION STATUS, SHOW PROCEDURE STATUS and SHOW EVENTS on every schema dump. The first error aborts the dump, and the syncer never stores the table and view metadata it had already collected. A customer on ApsaraDB for SelectDB kernel 4.1.9 (Alibaba Cloud's Doris kernel, built on Apache Doris 3.1.4) hits exactly that. SelectDB's kernel release notes for 4.1.9 say "移除 PL/SQL 存储过程和 package 能力" (PL/SQL stored procedures and packages removed), and 4.1.8, 4.0.12 and 5.0.5 carry the same bullet. SHOW (PROCEDURE | FUNCTION) STATUS is a rule of that grammar in Doris, so the server answers Error 1105: errCode = 2, detailMessage = no viable alternative at input 'SHOW FUNCTION'(line 1, pos 5). Every database on the instance then fails to sync, and the SQL Editor object browser stays empty with "Code 13: Internal". Apache Doris master made the same removal in apache/doris#58700 and restored an always-empty stub in apache/doris#66659 because it blocked Bytebase. No Apache Doris release lacks the rule (every 3.1, 4.0, 4.1 and 4.2 tag has it, and 2.1/3.0 accept the statement through the legacy parser); the vendor kernel does.

The probes never produced anything on these engines. StarRocks has no stored procedures or events and answers with an empty MySQL-shaped set. Doris returns PL/SQL procedure rows as ProcedureName, CatalogId, DbId, ..., which the MySQL-shaped scan misreads: a stock Doris 4.1.3 with one procedure fails the dump with failed to call getRoutineStmt("prod_tg", "0", "1789585700466"): ... no viable alternative at input 'SHOW CREATE 1789585700466', and SHOW CREATE PROCEDURE returns two columns where the scan expects six. Neither engine has CREATE EVENT. The routine and event steps could only ever succeed when they found nothing, so this PR removes them and their helpers, plus the unused sequenceStmtFmt and the mysqldump flag-list comment that no longer described the dump.

Error tolerance around the probes was rejected. It would keep sending a statement the vendor declared unsupported and would mask real failures on a driver two engines share. information_schema.routines is not a substitute either; the same upstream removal deleted its scanner.

Validation

• TestDumpSendsNoRoutineOrEventProbe runs Dump for Doris and StarRocks against a scripted database/sql driver that answers the catalog queries with the column shapes a live Doris 4.1.3 returns and rejects the routine probes with the vendor's error. It fails on origin/main with the customer's exact error chain and passes here, including under go test -count=2.
• End to end on a local rig: a server built from this branch syncs prod_tg through a MySQL-wire proxy in front of Apache Doris 4.1.3 (FE and BE alive) that rejects only SHOW (FUNCTION|PROCEDURE) STATUS. The sync returns {}, the metadata lists the table and view, and the proxy log shows no routine or event statement. Bytebase 3.19.0 against the same proxy reproduces the customer's error.
• gofmt, go vet, go test ./backend/plugin/db/starrocks/... and golangci-lint v2.13.2 on the package.

Two adjacent defects in the same file are left for a follow-up, because each changes stored dump text or sync results for every Doris database and deserves its own review: the Doris dump text still opens with the MySQL SET @OLD_UNIQUE_CHECKS guard, which Doris rejects on replay, and getServerVariable scans two columns from Doris's four-column SHOW VARIABLES and silently fails.

🤖 Generated with Claude Code