Today the CLI admin commands use a mix of RPC and SQL connections.
(They don't use the HTTP interface.)

For example, node decommission is RPC-only. node ls is SQL-only. debug zip uses both RPC and SQL.

We want everything to use a single protocol, ideally SQL. The reason why we want SQL is that the SQL server has the strongest authentication policies. IT would also enable using Kerberos tokens with the CLI client commands (as requested by customers, e.g. cockroach workloads - cc @BramGruneir )

Discussed this with @bdarnell . We can achieve this as follows: define SQL built-in functions for the various CLI commands. The built-in function would generate the command's results. The client-side program would then become a "dumb" SQL client that just issues the appropriate SQL queries.

The other advantage of this approach is that it then becomes possible to "run CLI admin commands" from a SQL shell, for example a UI tool.

Note that this feature might be rendered more secure by combining it with #51453.

A technical implementation detail for this approach: whatever service we make available via a SQL built-in function should also simultaneously become available over the HTTP REST API, using a similarly (ideally, identically) named endpoint.

For example, if I have a "command" SELECT crdb_internal.admin_node_status() I should have /api/v2/node/status (or something like that).

With this system, the debug zip command would send a SQL request for crdb_internal.admin_debug_zip() (or something like that) and there would also be a HTTP endpoint /api/v2/debug/zip (or something like that), which is incidentally a requirement for #51008.

cc @celiala who might be interested.

Jira issue: CRDB-6312