GUACAMOLE-2064: Add interactive database terminal protocols

[4m1nr]

What this does

Adds interactive, terminal-based access to five databases from within
Guacamole — MySQL/MariaDB, PostgreSQL, SQL Server, MongoDB, and Oracle —
implementing the feature requested in
GUACAMOLE-2064.

Following the approach suggested on the issue, guacd does not spawn a
command-line client (mysql, psql, …). Instead each protocol links the
database's own C client library and drives libguac-terminal directly,
presenting a prompt at which statements are typed, edited, and executed. As a
result, every feature Guacamole already provides for terminal protocols —
typescripts, graphical session recording, terminal resize, clipboard, and
shared / read-only sessions — works here unchanged.

How it is structured

All database-agnostic logic lives in one new convenience library,
libguac-dbshell (src/dbshell), modeled on src/common-ssh:

• Line editor — a byte-stream editor with cursor movement
  (Left/Right/Home/End), in-memory command history (Up/Down), UTF-8-aware
  insertion/deletion, the usual control shortcuts (Ctrl-A/E/K/U/W/L), and a
  parser that consumes-and-drops unknown escape sequences so arrow keys etc.
  never leak bytes into the buffer.
• Statement splitter — accumulates input and detects complete statements
  per dialect: MySQL, PostgreSQL, Transact-SQL, Oracle, and JSON. Handles
  single/double/backtick/bracket quoting, -- / # / block comments,
  PostgreSQL dollar-quoting (and $1 positional params), T-SQL GO batches,
  Oracle PL/SQL /-terminated blocks, and JSON brace/bracket balancing.
• Result table renderer — buffers an initial window of rows to compute
  column widths, then streams the remainder; mysql-style borders, right-aligned
  numeric columns, NULL rendering, width capping with an ellipsis. It
  strips control characters from every cell, so a malicious or compromised
  database server cannot inject terminal escape sequences (the DB analogue of
  CVE-2023-43826).
• REPL, generic plugin scaffold, and common connection settings shared by
  every protocol (hostname/port/credentials/database/timeout plus the full
  terminal, typescript, recording, and Wake-on-LAN parameter sets).

Each protocol plugin (src/protocols/{mysql,postgresql,mssql,mongodb,oracle})
is a thin driver implementing a small vtable:

Protocol	Library	Notable driver behavior
mysql	MariaDB Connector/C	non-blocking API (so teardown never blocks on a dead server); KILL QUERY cancel via a second connection; LOAD DATA LOCAL INFILE disabled
postgresql	libpq	asynchronous API; PQcancel; server notices rendered inline; dollar-quoting-aware
mssql	FreeTDS CT-Library	GO batches; server messages incl. PRINT; ct_cancel attention on Ctrl-C
mongodb	MongoDB C Driver	Extended-JSON command shell; automatic cursor getMore; \use / \show meta-commands
oracle	Oracle Call Interface	EZConnect; PL/SQL blocks; OCIBreak cancel

Build / packaging

• configure autodetects libmariadb, libpq, FreeTDS, and libmongoc and
  disables the corresponding protocol with a warning if absent (same pattern as
  the existing libwebsockets/Kubernetes check).
• Oracle is never built by default — its client (Oracle Instant Client) is
  proprietary and non-redistributable. It is enabled explicitly with
  --with-oracle=<instant-client-dir>.
• The guacd Dockerfile installs the four redistributable client libraries, so
  the official image gains MySQL/PostgreSQL/SQL Server/MongoDB support; Oracle
  is documented as a custom-image step.

⚠️ Open question for maintainers — OpenSSL in the Docker image. The four
database client packages on Alpine depend on openssl-dev (OpenSSL 3), which
cannot be installed alongside openssl1.1-compat-dev, the package the
image currently pins (the base image is held at Alpine 3.18 for that reason).
This PR therefore switches the image to openssl-dev; guacd and its existing
dependencies build and run against OpenSSL 3 in my testing (the full image
builds and all existing protocols — RDP/VNC/SSH/telnet/Kubernetes — are
present and load). I have kept the 3.18 base pin and only updated the
comment that explained it, rather than bumping the base image, to keep this
change minimal.

Context: the openssl1.1-compat-dev pin comes from
GUACAMOLE-1741, where
VeNCrypt VNC authentication broke against OpenSSL 3.0.8 due to a
libvncserver incompatibility (not a guacd one). The Alpine 3.18 pin was
then added in the still-open
GUACAMOLE-1891 because
Alpine 3.19 dropped the compat package; Alpine 3.18 has since reached
end-of-life (9 May 2025). That libvncserver blocker was fixed upstream in
LibVNCServer 0.9.15
(22 Dec 2024): "Fixed building with OpenSSL >= 3.0.0." Since the Dockerfile
already auto-selects the latest LibVNCServer release, the image is building
0.9.15+ today, so the original reason for the OpenSSL 1.1 pin appears to be
stale. Moving to openssl-dev here is therefore a step toward what
GUACAMOLE-1891 needs, and that ticket looks close to resolvable.

Why I did not also bump the base image off 3.18: I tried building on
alpine:latest (currently 3.24) and it is not a self-contained change — it
cascades into unrelated packaging churn: webkit2gtk-dev has been renamed
(to webkit2gtk-4.1-dev), and CMake 4 on newer Alpine hard-rejects the older
cmake_minimum_required(VERSION < 3.5) still declared by some bundled
dependency sources (the libvncserver build fails to configure), with more
likely behind it. That is a genuine base-image migration and belongs in
GUACAMOLE-1891, not in this feature PR, so I kept the 3.18 pin (Alpine 3.18
still ships OpenSSL 3.1, so openssl-dev works there) and only switched the
OpenSSL package.

The one thing I could not fully verify: that VeNCrypt VNC auth works
against libvncserver 0.9.15 + OpenSSL 3 (the exact scenario GUACAMOLE-1741 was
about). It is worth an explicit re-test before the pin is considered dead. If
you would rather the Docker packaging (and thus the OpenSSL switch and that
VeNCrypt re-test) be handled separately from this feature — e.g. under
GUACAMOLE-1891 — I'm happy to drop the Docker commit and file a follow-up; the
protocols build fine from source regardless, so this only affects the
convenience image. Please let me know which you'd prefer.

Testing

Unit tests (CUnit, make check): new suites for the line editor & input
parser, command history, the statement splitter across all five dialects, and
cell sanitization. Full suite: 160 tests across 7 suites, all passing
(was 123/6 before).

Manual / integration testing: built and ran guacd against live database
containers, opening real connections through the Guacamole protocol with a
typescript recording enabled and asserting on the recorded output:

• MySQL (mariadb:11), PostgreSQL (postgres:16), SQL Server
  (mcr.microsoft.com/mssql/server:2022), MongoDB (mongo:7), Oracle
  (gvenzl/oracle-free): SELECT rendering (bordered table, right-aligned
  numerics, "N rows in set" footer), banners, and clean disconnect.
• PostgreSQL: multi-line statement with continuation prompt, statement-error
  recovery (session survives), and UTF-8 round-trip (café).
• MySQL: wrong-password path renders ERROR 1045 and aborts cleanly.
• Oracle: multi-line BEGIN … END; / PL/SQL block followed by a SELECT … FROM dual (proves semicolons inside the block do not terminate early).
• MongoDB: \use, \show collections, insert, and find.
• docker build . produces a guacd image containing all four redistributable
  plugins; make check green with --with-oracle active.

-Werror -Wall clean; every function, parameter, struct member, and constant
is Doxygen-documented in the house style.

Related PRs

Part of a three-repo change under GUACAMOLE-2064:

• Server (this PR): GUACAMOLE-2064: Add interactive database terminal protocols #694
• Client (web UI / forms / translations): GUACAMOLE-2064: Add UI support for database terminal protocols guacamole-client#1229
• Manual (documentation): GUACAMOLE-2064: Document database terminal protocols guacamole-manual#299

[mike-jumper]

Haven't read through this yet, but in principle I like the idea. It's broad and would be an interesting addition to the suite of supported protocols.