62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…ion that carries semantics

Two textual conflicts, both in ConnectorPluginManager, both from upstream apache#65644
adding a plugin-inventory registration into the exact loop bodies this branch had
already given an admission gate. Resolution is the union, with one deliberate
narrowing: registerDiscovered stays outside upstream's catch(RuntimeException),
because its fail-loud IllegalStateException reports a build error and would
otherwise be silently downgraded to warn-and-skip.

Also records what the four verification layers actually covered, and the two
things they did not: those loop bodies have no test on either side, and the
merged loadPlugins now has one reject path that discards the plugin classloader
and one that does not.

… reject path

Merging this branch's admission gate into the loadPlugins loop that upstream
apache#65644 had just restructured left the loop with two reject paths and only one
of them releasing the plugin's classloader: the name-conflict path discarded,
the registerDiscovered path did not. FileSystemPluginManager, the sibling this
loop mirrors, discards on both of its reject paths.

Safe because a false return from registerDiscovered has claimed nothing — the
claimedTypes add is short-circuited while a problem is pending, claimedEngineNames
is untouched and the provider never reaches the providers list — so no part of the
manager still references that classloader. No extra log line: registerDiscovered
already reports why it refused.

fe-core targeted 26/26, checkstyle 0. The loop body itself remains untested on
both sides; see the handoff for why a test there was judged not worth its cost.

…tadata (apache#65644)

### What problem does this PR solve?

Issue apache#65479

Kernel plugin families (filesystem, connector, authentication, lineage)
currently have no unified, queryable inventory: to know which plugins
are loaded on an FE, one has to read logs. This PR adds a unified
`information_schema.plugins` system table listing all successfully
loaded kernel plugins of the currently connected FE.

Columns: `PLUGIN_NAME`, `PLUGIN_TYPE`, `PLUGIN_VERSION`, `SOURCE`,
`DESCRIPTION`.

Design points:
- `(plugin_type, plugin_name)` is the primary key, enforced at load
time: the first registration wins and is never silently overridden, so a
directory jar can never displace a built-in plugin.
- `name()` / `description()` are snapshotted once at load time; querying
the table never executes plugin code. A broken self-report fails the
load.
- Plugin names are validated at load (trimmed, non-blank, <=64 chars,
`[A-Za-z0-9._-]`); an invalid name fails the load for external plugins.
- `PLUGIN_VERSION` comes from the jar MANIFEST `Implementation-Version`
(NULL when unavailable), never from plugin interface methods.
- Only successfully loaded plugins appear; load failures go to logs. No
status/fail_reason columns.
- Querying requires global ADMIN privilege; non-admin users see no rows.
- View semantics are per-FE: the BE scanner RPCs the currently connected
FE (same pattern as `catalog_meta_cache_statistics`), so per-FE jar
deployment can be audited connection by connection.

Implementation:
- `fe-extension-spi`: add `default String description()` to
`PluginFactory` (empty by default, zero migration cost).
- `fe-extension-loader`: new process-wide `PluginRegistry` (load-time
snapshots only) and `PluginNames` validation;
`DirectoryPluginRuntimeManager` snapshots name/description and reads
`Implementation-Version` from the jar containing the factory class.
- The four family managers register BUILTIN/EXTERNAL rows; filesystem
and connector managers now also reject external providers whose name
conflicts with an already-registered one.
- FE: `SchemaTable` definition + `MetadataGenerator` data source; thrift
`TSchemaTableName.PLUGINS`. Reuses the existing MySQL-compat
`TSchemaTableType.SCH_PLUGINS`.
- BE: new `schema_plugins_scanner` wired into `schema_scanner`.

Example:

```
mysql> SELECT * FROM information_schema.plugins;
+-------------+----------------+----------------+---------+---------------------------+
| PLUGIN_NAME | PLUGIN_TYPE    | PLUGIN_VERSION | SOURCE  | DESCRIPTION               |
+-------------+----------------+----------------+---------+---------------------------+
| hdfs        | FILESYSTEM     | NULL           | BUILTIN |                           |
| jdbc        | CONNECTOR      | NULL           | BUILTIN |                           |
| oidc        | AUTHENTICATION | 4.0.0          | EXTERNAL| OIDC authentication       |
+-------------+----------------+----------------+---------+---------------------------+
```

### Release note

Add `information_schema.plugins` system table listing loaded kernel
plugins (filesystem/connector/authentication/lineage) of the currently
connected FE; requires ADMIN privilege.

### Check List (For Author)

- Test
- [x] Unit test: `PluginRegistryTest`,
`DirectoryPluginRuntimeManagerMetadataTest`
- [x] Regression test:
`regression-test/suites/query_p0/schema_table/test_plugins_schema.groovy`

- Behavior changed:
    - [x] Yes, new `information_schema.plugins` table (additive only).

- Does this need documentation?
- [x] Yes, `information_schema.plugins` should be documented as a new
system table.

62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…ion that carries semantics

Two textual conflicts, both in ConnectorPluginManager, both from upstream apache#65644
adding a plugin-inventory registration into the exact loop bodies this branch had
already given an admission gate. Resolution is the union, with one deliberate
narrowing: registerDiscovered stays outside upstream's catch(RuntimeException),
because its fail-loud IllegalStateException reports a build error and would
otherwise be silently downgraded to warn-and-skip.

Also records what the four verification layers actually covered, and the two
things they did not: those loop bodies have no test on either side, and the
merged loadPlugins now has one reject path that discards the plugin classloader
and one that does not.

… reject path

Merging this branch's admission gate into the loadPlugins loop that upstream
apache#65644 had just restructured left the loop with two reject paths and only one
of them releasing the plugin's classloader: the name-conflict path discarded,
the registerDiscovered path did not. FileSystemPluginManager, the sibling this
loop mirrors, discards on both of its reject paths.

Safe because a false return from registerDiscovered has claimed nothing — the
claimedTypes add is short-circuited while a problem is pending, claimedEngineNames
is untouched and the provider never reaches the providers list — so no part of the
manager still references that classloader. No extra log line: registerDiscovered
already reports why it refused.

fe-core targeted 26/26, checkstyle 0. The loop body itself remains untested on
both sides; see the handoff for why a test there was judged not worth its cost.

62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

62 commits replayed; the only conflicts were two import-block unions in
MetadataGenerator.java (upstream #65644's PluginRegistry import landing between
our datasource.plugin.PluginDriven* imports). Zero capability migration this
round: #65987's JDBC hardening already targets fe-connector-jdbc upstream and
its JdbcResource half is shared, #65644's plugin inventory was verified safe for
all 8 of our connectors, and the other three upstream commits are BE-only.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…tadata (apache#65644)

### What problem does this PR solve?

Issue apache#65479

Kernel plugin families (filesystem, connector, authentication, lineage)
currently have no unified, queryable inventory: to know which plugins
are loaded on an FE, one has to read logs. This PR adds a unified
`information_schema.plugins` system table listing all successfully
loaded kernel plugins of the currently connected FE.

Columns: `PLUGIN_NAME`, `PLUGIN_TYPE`, `PLUGIN_VERSION`, `SOURCE`,
`DESCRIPTION`.

Design points:
- `(plugin_type, plugin_name)` is the primary key, enforced at load
time: the first registration wins and is never silently overridden, so a
directory jar can never displace a built-in plugin.
- `name()` / `description()` are snapshotted once at load time; querying
the table never executes plugin code. A broken self-report fails the
load.
- Plugin names are validated at load (trimmed, non-blank, <=64 chars,
`[A-Za-z0-9._-]`); an invalid name fails the load for external plugins.
- `PLUGIN_VERSION` comes from the jar MANIFEST `Implementation-Version`
(NULL when unavailable), never from plugin interface methods.
- Only successfully loaded plugins appear; load failures go to logs. No
status/fail_reason columns.
- Querying requires global ADMIN privilege; non-admin users see no rows.
- View semantics are per-FE: the BE scanner RPCs the currently connected
FE (same pattern as `catalog_meta_cache_statistics`), so per-FE jar
deployment can be audited connection by connection.

Implementation:
- `fe-extension-spi`: add `default String description()` to
`PluginFactory` (empty by default, zero migration cost).
- `fe-extension-loader`: new process-wide `PluginRegistry` (load-time
snapshots only) and `PluginNames` validation;
`DirectoryPluginRuntimeManager` snapshots name/description and reads
`Implementation-Version` from the jar containing the factory class.
- The four family managers register BUILTIN/EXTERNAL rows; filesystem
and connector managers now also reject external providers whose name
conflicts with an already-registered one.
- FE: `SchemaTable` definition + `MetadataGenerator` data source; thrift
`TSchemaTableName.PLUGINS`. Reuses the existing MySQL-compat
`TSchemaTableType.SCH_PLUGINS`.
- BE: new `schema_plugins_scanner` wired into `schema_scanner`.

Example:

```
mysql> SELECT * FROM information_schema.plugins;
+-------------+----------------+----------------+---------+---------------------------+
| PLUGIN_NAME | PLUGIN_TYPE    | PLUGIN_VERSION | SOURCE  | DESCRIPTION               |
+-------------+----------------+----------------+---------+---------------------------+
| hdfs        | FILESYSTEM     | NULL           | BUILTIN |                           |
| jdbc        | CONNECTOR      | NULL           | BUILTIN |                           |
| oidc        | AUTHENTICATION | 4.0.0          | EXTERNAL| OIDC authentication       |
+-------------+----------------+----------------+---------+---------------------------+
```

### Release note

Add `information_schema.plugins` system table listing loaded kernel
plugins (filesystem/connector/authentication/lineage) of the currently
connected FE; requires ADMIN privilege.

### Check List (For Author)

- Test
- [x] Unit test: `PluginRegistryTest`,
`DirectoryPluginRuntimeManagerMetadataTest`
- [x] Regression test:
`regression-test/suites/query_p0/schema_table/test_plugins_schema.groovy`

- Behavior changed:
    - [x] Yes, new `information_schema.plugins` table (additive only).

- Does this need documentation?
- [x] Yes, `information_schema.plugins` should be documented as a new
system table.

…el plugin metadata (#68176)

#65644

---------

Signed-off-by: Aurélien Pupier <[email protected]>
Co-authored-by: Aurélien Pupier <[email protected]>