CIBuildUploadJob fails if a build produces multiple versions of the same binary package name in the same format

[Dan Ryan]

As part of SOSS, I am publishing a python package (clang) to artifactory via `lpcraft release`. The build in question contains multiple wheels and multiple sdists (a single build of the package produces multiple versions). When I attempt the release, I receive an email which contains the following OOPS: OOPS-a998fe1a66a7d066ba9cc7ac0b8f1ff8

This seems to point to a database constraint, but I have verified that there is no source or binary for the relevant source package in the target PPA via the API:

```
>>> archive = lp.archives.getByReference(name=ppa)
>>> binaries = [_ for _ in archive.getPublishedBinaries() if _.status in ("Published", "Pending")]
>>> sources = [_ for _ in archive.getPublishedSources() if _.status in ("Published", "Pending")]
>>> len([_ for _ in binaries if _.binary_package_name == "clang"])
0
>>> len([_ for _ in sources if _.source_package_name == "clang"])
0
```

[Colin Watson (cjwatson)]

The database constraint violation here is internal to that build, and the whole thing is rolled back transactionally on failure, which is why you don't see any trace of it. The assumption in place is that any given CI build can only produce one "release" of a given binary package name in a given format - but this one is trying to produce clang 11.1, 12.0.1, and 13.0.1 from the same build.

If we were to fix this, then I think we'd need to make `CIBuildUploadJob._uploadBinaries` include a version element in the `releases` dictionary, correct the oversight where newly-created BPRs aren't inserted into the `releases` dictionary, and then once that's deployed we could (I think) weaken that DB constraint so that it also includes a version element.

However, I'm not sure we should do this, because it has somewhat weird behaviour. If we think ahead to when this is fetching and repackaging locally-built artifacts instead and when we have a pipeline to automatically trigger rebuilds as needed, then it's going to rebuild all three versions when one of them changes. Even today, this layout means you can only update all three at once. IMO this is an antipattern that we should avoid even if the result is a slightly less convenient git layout.

So, overall, I can see why you thought it was most expedient to do this, but I can't recommend it at the moment. The simplest workaround would be to have three very similar branches that just have different `package.lst` files causing them to build a single sdist-and-wheel pair each, and release each of them separately.