store: replace namesgenerator with neutral builder IDs

[crazy-max]

This removes the remaining github.com/docker/docker dependency from Buildx by replacing the old namesgenerator usage in the store with neutral autogenerated builder names. The new format uses builder_ plus a short identity.NewID() suffix, which keeps generated names predictable enough for current Buildx behavior without carrying the daemon-style human-readable naming scheme.

The existing driver-side runtime name derivation is unchanged, so autogenerated builders still flow through the current buildx_buildkit_ prefixing path for derived node and container names. In practice that means a builder such as builder_abc123def456 still becomes builder_abc123def4560 at the node level and buildx_buildkit_builder_abc123def4560 at the runtime object level, with Kubernetes continuing to normalize underscores to hyphens when deriving deployment names.

This is the smaller follow-up to the earlier work in #3354. The in-tree human-readable replacement there was not the right long-term direction. The concern raised in the earlier discussion was not just the dependency itself, but also that Buildx should not keep copying the daemon's naming style for builder identities. Using a neutral generated identifier keeps this change scoped to dependency removal, without coupling it to a broader redesign of builder presentation.

This PR intentionally doesn't try to solve the separate TOCTOU and ownership issues discussed in #3354 and the linked follow-ups. Buildx still reserves a builder name in the local store first and later derives node and container names from it, so there is still a window where conflicting objects can appear between reservation and container creation even though this is more unlikely with this change. So that needs explicit follow-up work around ownership labeling and verification before reuse or removal, and it should be handled separately.

[thaJeztah]

Wondering if we need the complexity of identity here; would something like this give enough randomness?

import (
	"math/rand/v2"
	"encoding/hex"
)

func NewID() string {
	var b [8]byte // 64 bits
	rand.Read(b[:])
	return hex.EncodeToString(b[:]) // 16 hex chars
}

[thaJeztah]

Oh; and I just recalled I did something similar for k8s some time ago;

buildx/driver/kubernetes/util/generate.go

Lines 56 to 75 in d5d3d3d

	// generateName generates the name plus a random suffix of five alphanumerics
	// when a name is requested. The string is guaranteed to not exceed the length
	// of a standard Kubernetes name (63 characters).
	//
	// It's a simplified implementation of k8s.io/apiserver/pkg/storage/names:
	// https://github.com/kubernetes/apiserver/blob/v0.29.2/pkg/storage/names/generate.go#L34-L54
	func generateName(base string) string {
	if len(base) > maxGeneratedNameLength {
	base = base[:maxGeneratedNameLength]
	}
	return base + randomSuffix()
	}
	func randomSuffix() string {
	b := make([]byte, 32)
	if _, err := rand.Read(b); err != nil {
	panic(err) // This shouldn't happen
	}
	return hex.EncodeToString(b)[:randomLength]
	}

[thaJeztah]

As we're changing, might as well use - instead of _ (which should produce a more correct hostname for the container if there's ever a need for that).

[crazy-max]

I used builder_ intentionally because Buildx already derives runtime names through the buildx_buildkit_ prefix, so underscores are already part of the existing naming convention here. And it's a bit easier to read and copy/paste consistently alongside the derived node and runtime names.

[thaJeztah]

Not for this PR probably , but looks like we have some different patterns in different packages;

buildx/bake/bake.go

Lines 40 to 41 in 09f288c

	validTargetNameChars = `[a-zA-Z0-9_-]+`
	targetNamePattern = regexp.MustCompile(`^` + validTargetNameChars + `$`)

I know these regexes are rather memory-hungry; we could even rewrite these to a basic function to loop; I recall we did similar changes elsewhere, e.g.; https://github.com/moby/moby/blob/dff719e3674958407416fd1d8a35db998f128da2/daemon/internal/stringid/stringid.go#L62-L70