hcp: give a proper error when using conflicting build name

[mogrogan]

It was possible to put the same source 2 times in the build and when using HCP, it would error eventually since they are considered the samebuild from HCP side

Test

packer {
  required_plugins {
    docker = {
      version = ">= 1.0.8"
      source = "github.com/hashicorp/docker"
    }
  }
}

source "docker" "ubuntu-jammy" {
  image  = "ubuntu:jammy"
  commit = true
}

source "docker" "ubuntu-focal" {
  image  = "ubuntu:focal"
  commit = true
}

build {
  name = "jammy-build-block"

  hcp_packer_registry {
    bucket_name = "test-root"
    description = "hcp test with root"
  }
  sources = [
    "source.docker.ubuntu-jammy",
    "source.docker.ubuntu-jammy",
  ]
}

This would give this error:

$ packer build .
Error: Build name conflicts

When using HCP registry, build names are used as identifier. In this case, there
is 2 or more build called jammy-build-block.docker.ubuntu-jammy

[lbajolet-hashicorp]

Overall this looks good to me, I think it maintains existing compatibility, but to be sure, have you run HPATS on those?
I left a couple comments, but nothing blocking, I'll let you address those and come back for another round of review later.

[lbajolet-hashicorp]

Nit: this could be renamed to expectErr to clarify intent

[lbajolet-hashicorp]

I wonder if we can add a lead for solving this conflict in this case, like adding a name to the build block if relevant.
I would also suggest adding a Subject here to have a location in the error message so users know where to look in order to fix the error.

[mogrogan]

Currently, the only way to get a conflict is by using the same source on the build block. We probably should add a more precise message error once we support multiple build block

[lbajolet-hashicorp]

Suggested change

	// set will return true if properly inserted and false if the values is conflicting
	// set will return true if properly inserted and false if the values are conflicting

[lbajolet-hashicorp]

I'm not necessarily against the idea of introducing a structure for this, but it feels a bit verbous to get them, I wonder if having functions directly on HCLRegistry wouldn't be better for this purpose?

[lbajolet-hashicorp]

Come to think of it, since we change how we get the build names, does that impact that MetadataStore? It might not but I just want to be sure we considered delving into this before this gets merged, so that we don't break things later down the line

[lbajolet-hashicorp]

Assuming we remove that structure, this function is a one-time use thing, so the code might as well be rolled into the function that adds the builds I'd think

[lbajolet-hashicorp]

Assuming this is rolled into the function (or not even), the signature could be changed to accept a *CoreBuild instead, so we can do the logic of getting the build from the source/build name combination if relevant