An Azure Blob Storage backend cannot be scoped to a prefix, so one container cannot hold two Arc deployments

[xe-nvdk]

⚠️ Internal work only. Community contributions are not being accepted for this issue.

Basekick Labs is implementing this internally. Please do not open PRs against it; they will be closed without review. Discussion and questions in the comments are welcome.

Summary

S3Config has a Prefix (internal/storage/s3.go:77-86), validated by ValidateS3Prefix and applied to every key through prefixedKey / prefixedListPrefix, so an operator can put Arc's data under arc/ in a bucket that holds other things, or run two deployments in one bucket under different prefixes.

AzureBlobConfig (internal/storage/azure.go:33-52) has no equivalent field, and internal/storage/util.go:85-87 states the position explicitly:

case *AzureBlobBackend: // Azure has no prefix concept: the key IS the blob name.
    return "azure://" + b.containerName + "/"

So on Azure the only scoping unit is the container. Consequences for an operator who has one:

• Two Arc deployments cannot share a container, even under disjoint prefixes.
• Arc's data cannot live beside anything else in a container, because the data listing walks from the container root.
• The three Azure config keys that exist for the primary backend, the cold tier and (with backup (stage B): named remote targets (local, S3, Azure) with per-database routing #1085) a backup target all inherit the limitation, so the gap is not specific to any one of them.

Azure itself has no native prefix, but a blob name is a flat string and every SDK listing call takes a prefix, which is exactly how the S3 backend implements it.

Expected

AzureBlobConfig gains a Prefix validated by the same rules the S3 prefix uses (ValidateS3Prefix is already generic in everything but its name), applied in the same two places: a prefixedKey for every operation that names a blob, and a prefixedListPrefix for every listing. backendRoot (util.go:81-94) and its comment are updated, and the ListUnusable path checked alongside, since it builds its own listing.

Notes

• Wanted by stage B of the backup work (backup (stage B): named remote targets (local, S3, Azure) with per-database routing #1085): a named backup target takes a key prefix for every type, and a prefixing wrapper around storage.Backend is not an option there because the backup code type-asserts four optional interfaces on the backend (BatchDeleter, UnusableLister, ObjectLister, StagingInspector) and a wrapper holding the interface hides them. Losing ObjectLister in particular makes a restore re-create compaction inputs, the hazard backup: compaction recovery manifests are not backed up, so a restore can serve compacted rows twice #930 exists to prevent. So the prefix has to be native.
• ValidateS3Prefix's doc comment (s3.go:778-795) records how the previous repairing version silently sent writes to the bucket root; whatever validates the Azure prefix should reuse it rather than re-derive the rules.