Add secure Quack protocol support to the DuckDB storage engine

Problem

The DuckDB storage engine should be accessible through DuckDB's Quack client protocol without bypassing MariaDB authentication, roles, and object privileges.

A direct Quack connection currently has no MariaDB THD or Security_context. DuckDB itself has no MariaDB-compatible users or grants, and unrestricted DuckDB SQL can access the shared catalog, files, networks, extensions, secrets, and global settings.

Proposed design

Implement a deny-by-default Quack integration in the DuckDB storage engine:

• Keep Quack disabled by default and start the listener only after all security components initialize.
• Authenticate Quack connections directly, without requiring a separate MariaDB client session or token-minting query.
• Support verified-TLS client-first authentication for an explicitly supported account subset; add Unix peer authentication when Quack supports Unix-domain sockets; later expose MariaDB fast challenge-response and generic authentication-plugin exchanges.
• Attach an immutable MariaDB principal and active role to the actual server-side DuckDB ClientContext.
• Register a DuckDB PlannerExtension::post_bind_function and derive table, column, and DML access from the bound logical plan instead of SQL-prefix or regex checks.
• Send copied access requests to a bounded MariaDB ACL worker owning a pre-created background THD.
• Enforce current global, database, table, column, role, and PUBLIC grants through MariaDB ACL APIs. GRANT and REVOKE must affect subsequent statements without copying the grant catalog into DuckDB.
• Filter Quack catalog discovery by the authenticated principal.
• Deny unknown logical operators, arbitrary table functions, external I/O, ATTACH, extension management, secrets, global settings, and DDL until explicitly supported.
• Ensure optimized append or bulk protocol messages cannot bypass column-level authorization.
• Add table autodiscovery, metadata invalidation, MDL coordination, binlog, and replication behavior before enabling DDL through Quack.

First usable milestone

• Quack is disabled by default and listens only on an explicitly configured secure endpoint.
• Every accepted Quack connection maps to an authenticated MariaDB principal.
• One bounded ACL worker checks live MariaDB grants on a background THD.
• Base-table SELECT is authorized after DuckDB binding, including table and column grants, active roles, and PUBLIC.
• Catalog discovery returns only visible objects.
• DML, DDL, table functions, external I/O, extension management, secrets, and settings are denied.
• Authentication and authorization errors fail closed; no configuration or error path installs allow-all callbacks.
• Audit/status counters cover accepted and rejected connections, authorization outcomes, timeouts, queue saturation, and active sessions.

Follow-up milestones

1. INSERT, UPDATE, DELETE, INSERT ... SELECT, conflict-update, and structured append authorization.
2. MariaDB native/PARSEC fast authentication and generic authentication-plugin integration.
3. Controlled DDL after table discovery, metadata locking/invalidation, binlog, and replication semantics are implemented.

Test requirements

Cover authentication failures, host-specific accounts, locked accounts, roles, global/database/table/column grants, concurrent GRANT/REVOKE, joins/CTEs/subqueries/views, blocked external capabilities, metadata filtering, queue timeout/saturation, disconnect and shutdown races, and debug/release builds.