mariadb-dump does not use SET PATH

For procs, funcs, triggers, and views, MariaDB 12.3's new SET PATH feature (from MDEV-34391) is remembered from creation time of the object. However, mariadb-dump does not interact with it yet, resulting in dumps that omit any necessary SET PATH statements. This can then lead to failed view creation when replaying the dump, as well as procs/funcs/triggers that fail when they attempt to be used.

Repro:

CREATE DATABASE a;

USE a;

CREATE FUNCTION f() RETURNS int RETURN 42;

CREATE DATABASE b;

USE b;

CREATE TABLE t (id int NOT NULL, name varchar(30), PRIMARY KEY (id));

SET PATH 'a';

CREATE TRIGGER tr BEFORE INSERT ON t FOR EACH ROW SET @foo = f();

CREATE VIEW v AS SELECT f() AS foo;

CREATE FUNCTION ff() RETURNS int RETURN f();

Then dump with --routines enabled, e.g.

mariadb-dump -h ... --routines --databases a b >/some/dump/file.sql

In a new clean mariadb server and a session that doesn't manually set PATH, try to source the dump:

• The CREATE VIEW statement from the dump immediately fails with ERROR 1305 "FUNCTION b.f does not exist".
• The other statements succeed (since function and trigger bodies are allowed to reference nonexistent functions at creation time) but fail at execution time, e.g. SELECT b.ff() fails, and attempting to INSERT into t fails due to the trigger tr.

Part of the problem here is the creation-time PATH isn't actually exposed anywhere in information_schema or SHOW CREATE, so clients (including mariadb-dump) don't even have a good place to query for them yet, as far as I can tell. (Technically they're in mysql.proc.path for routines, but nowhere for views or triggers.)

Also see MDEV-39929 regarding events – currently PATH does not affect events at all yet, but if that is fixed, then events similarly would need PATH to be exposed in information_schema and SHOW CREATE, and proper handling in mariadb-dump.