Avoid losing source location information when vertices duplicate

[ktock]

When a LLB contains duplicated vertcies with different source information, it's possible that some of the location infomations are lost.
This is make it difficult to do source-level debugging for some vertecies.
This commit fixes this issue.

e.g.

FROM ghcr.io/stargz-containers/ubuntu:20.04-org AS a
FROM ghcr.io/stargz-containers/ubuntu:20.04-org AS b
FROM scratch
COPY --from=a / /
COPY --from=b / /

master branch

Location info of FROM at line 2 is lost.

{
  "locations": {
    "sha256:20ed82fdf481a640454f8113dde5f2e292c725b9b0dff5082c6a3b0c9470e186": {
      "locations": [
        {
          "ranges": [
            {
              "start": {
                "Line": 1
              },
              "end": {
                "Line": 1
              }
            }
          ]
        }
      ]
    },
    "sha256:f1768aff48a1c6860a01777144ff6eea79748963a56aa490f61680e2e37c732c": {
      "locations": [
        {
          "ranges": [
            {
              "start": {
                "Line": 4
              },
              "end": {
                "Line": 4
              }
            }
          ]
        }
      ]
    },
    "sha256:f956b50ddb2ae43f5917de1a5a8841764da7dd502b3c97891575288327a44785": {
      "locations": [
        {
          "ranges": [
            {
              "start": {
                "Line": 5
              },
              "end": {
                "Line": 5
              }
            }
          ]
        }
      ]
    }
  },
  "infos": [
    {
      "filename": "dummy",
      "data": "RlJPTSBnaGNyLmlvL3N0YXJnei1jb250YWluZXJzL3VidW50dToyMC4wNC1vcmcgQVMgYQpGUk9NIGdoY3IuaW8vc3Rhcmd6LWNvbnRhaW5lcnMvdWJ1bnR1OjIwLjA0LW9yZyBBUyBiCkZST00gc2NyYXRjaApDT1BZIC0tZnJvbT1hIC8gLwpDT1BZIC0tZnJvbT1iIC8gLwo="
    }
  ]
}

PR

All information is preserved.

{
  "locations": {
    "sha256:20ed82fdf481a640454f8113dde5f2e292c725b9b0dff5082c6a3b0c9470e186": {
      "locations": [
        {
          "ranges": [
            {
              "start": {
                "Line": 2
              },
              "end": {
                "Line": 2
              }
            }
          ]
        },
        {
          "ranges": [
            {
              "start": {
                "Line": 1
              },
              "end": {
                "Line": 1
              }
            }
          ]
        }
      ]
    },
    "sha256:f1768aff48a1c6860a01777144ff6eea79748963a56aa490f61680e2e37c732c": {
      "locations": [
        {
          "ranges": [
            {
              "start": {
                "Line": 4
              },
              "end": {
                "Line": 4
              }
            }
          ]
        }
      ]
    },
    "sha256:f956b50ddb2ae43f5917de1a5a8841764da7dd502b3c97891575288327a44785": {
      "locations": [
        {
          "ranges": [
            {
              "start": {
                "Line": 5
              },
              "end": {
                "Line": 5
              }
            }
          ]
        }
      ]
    }
  },
  "infos": [
    {
      "filename": "dummy",
      "data": "RlJPTSBnaGNyLmlvL3N0YXJnei1jb250YWluZXJzL3VidW50dToyMC4wNC1vcmcgQVMgYQpGUk9NIGdoY3IuaW8vc3Rhcmd6LWNvbnRhaW5lcnMvdWJ1bnR1OjIwLjA0LW9yZyBBUyBiCkZST00gc2NyYXRjaApDT1BZIC0tZnJvbT1hIC8gLwpDT1BZIC0tZnJvbT1iIC8gLwo="
    }
  ]
}

[tonistiigi]

This is somewhat related to #2820 . We could add more source locations to the LLB request but that doesn't mean that there is any guarantee that this metadata will end up in the vertex that is in the solver graph. This would possibly fix the issue with the same request referring to identical LLB in multiple places but if it is different requests then the metadata still gets dropped. @sipsma

[tonistiigi]

I think I might have got confused when I reviewed this the first time. It looks like sources don't currently get stored in the graph with the vertexes at all (this is something I would want to do in the future though to also map source to result refs). But currently, they are only on error handling that is specific to one build request.