A vendor's modules each carry a copy of the vendor's settings, and core has no table they share #1284

The problem

A vendor with several modules, say a device module, a geo module and an identifier module, calls one service with one key. Each module is selected by its own section and reads its own table, so the endpoint and the key are written once in each table, and a module cannot be built on what another module's table says. Nothing in core lets a vendor say that its modules run together or not at all.

The change

Core declares [shared.<vendor>], one table per vendor named by the vendor's folder under crates/shared, holding what every module of that vendor reads. Core reads none of them. A vendor's crates read their own as typed settings through Settings::shared_config, which refuses a table that cannot be read as the type or fails its validation, naming the table. A table whose name is not a folder name is refused when the settings load.

[shared.example]
endpoint = "https://api.example.com/v1"
license_key = "example_license_key"

A builder marked with with_shared_settings is run by its vendor's table rather than by a selection. Settings without the table run none of that vendor's modules, a selection naming one of them is refused with the absent table named, and a table that no builder reads is refused when the registry is built, the one place every builder is known. A secret in the table is declared at its path inside the table through the builder's secret settings, as a module's own secrets are, resolved from the secret store when the table is present.

The seam probe gains a second builder its table runs, whose route answers the table's marker, so the Axum adapter proves the table from outside core.

Where it is

Draft on the fork, jwrosewell#21, on top of robots.txt as a middleware (fork pull request 20).