feat(server): configure buildx driver via plugin configuration

[alexey-igrychev]

Summary

A project can now choose its buildx driver and driver options through configure, instead of only through the environment of the Vault process. That is the only route available when the secret engine is compiled into a host process whose environment the administrator cannot set, where the kubernetes driver was unreachable until now.

Continues #412 by @vmrm, rebased onto main after #409.

What

• configure accepts buildx_driver — docker-container or kubernetes, empty by default — and it wins over TRDL_BUILDX_DRIVER.
• configure accepts buildx_driver_opts — a list, one --driver-opt per element, empty by default — and it wins over TRDL_BUILDX_DRIVER_OPTS_*. Elements are passed through verbatim, so nodeselector=disktype=ssd,zone=a stays one option.
• Each of the two settings resolves on its own: configuration, then environment, then the previous default of docker-container with no options. A field omitted or set to a blank value means "not configured" and falls back to the environment instead of clearing it, so building with no options while the environment defines some requires unsetting those variables.
• An unsupported driver is rejected whatever its source: writing buildx_driver=docker fails configure and stores nothing, while an unsupported TRDL_BUILDX_DRIVER still fails when the builder is created. The error names the setting the value came from.
• configure rejects buildx_driver or buildx_driver_opts written together with buildkitd_address, and leaves an already stored configuration untouched: that address replaces the buildx path entirely, so the driver settings would have no effect. Blank values count as unset on both sides of that check.
• When the address comes from TRDL_BUILDKITD_ADDRESS instead, the combination cannot be refused at write time — the variable is process-wide and can change after a project is configured — so the release reports the configured buildx driver settings are not used in both the release task log and the plugin log.
• An update that omits the buildx fields clears the stored ones: configure replaces the whole document.
• With neither field set, docker buildx create is invoked exactly as before, down to the argument list, and a configuration stored before these fields existed reads back with both fields empty and builds as it did.
• UNVERIFIED: that buildx_driver_opts and buildkitd_address reach the release build at all — deleting their assignment in pathRelease leaves every suite green. The driver now has an end-to-end guard; these two would need one job each, because the value has to break the build when it is lost.

Why

Everything else a project needs already lives in configure — the Git repository, the S3 credentials, the signature quorum — because Vault has no other per-project channel. The build backend was the exception: it could only be set through the environment of the process that hosts the plugin, and a host process that ships the engine as a built-in plugin may expose no way to set one, which left such an installation on the default driver permanently.

Environment-only was the alternative, and #409 shows why it does not hold: the same argument produced buildkitd_address as a configure field, so keeping the driver out of configure would have split one decision across two mechanisms.

[alexey-igrychev]

Verification

• Mutation: rejection removed from pathConfigureCreateOrUpdate → both subtests of TestAI_CreateOrUpdate_BuildxFieldsRejectedWithBuildkitdAddress failed.
• Mutation: rejection moved below putConfiguration → TestAI_CreateOrUpdate_RejectedCombinationKeepsConfiguration failed, while the pre-existing unsupported-driver test survived, which is why that test was added.
• Mutation: TrimSpace dropped from the address and from the option elements → both subtests of TestAI_CreateOrUpdate_BlankValuesAreNotACombination failed.
• Mutation: the "settings unused" log line removed → TestAI_NewBuilder_ReportsUnusedBuildxSettingsInBuildkitMode failed.
• Mutation: both forwarding lines deleted from pathRelease → every unit suite stayed green, which is what the new e2e_buildx_config job now covers.
• An independent review found that TestAI_BuildReleaseArtifacts_ForwardsConfiguredDriver and TestAI_NewBuilder_UsesConfiguredDriver relied on driver validation to stop the build before docker buildx create: with the resolution precedence inverted, the first provisioned a real BuildKit Deployment in the reviewer's cluster and then deadlocked on an artifacts pipe nobody read, reporting no failure at all. Both now run with an empty PATH and the pipe is drained.
• Not run: the kubernetes driver against a real cluster with the driver supplied by configure. Tests. Buildx kubernetes driver is opt-in and drives it through the environment, so that combination is covered by unit tests only.
• The mutation table from feat(server): configure buildx driver via plugin configuration #412 was not re-run after the rebase; those tests pass unchanged, and the rebase touched declarations rather than the resolution logic they cover.

Review focus

• resolveBuildxDriverOpts — the asymmetry a reader will trip on: an explicitly empty list falls back to the environment rather than clearing it, because configure cannot distinguish an omitted field from an empty one.
• The rebase resolved six files by hand against feat(server): build via BuildKit client when buildkitd address is set #409 (path_configure.go, path_configure_test.go, path_release.go, pkg/docker/build.go, pkg/docker/builder.go and the generated configure partial); worth a look that both features survived intact.

Follow-up

• Close feat(server): configure buildx driver via plugin configuration #412 with a link to this PR, and tell the author about the two non-hermetic tests.
• Guard the pathRelease forwarding of buildx_driver_opts and of buildkitd_address from feat(server): build via BuildKit client when buildkitd address is set #409 the way e2e_buildx_config guards the driver.