Add /transition_packages API (Closes: #204)

[jspricke]

No description provided.

[h01ger]

fwiw, we're running this on r.d.n. since yesterday.

[jspricke]

@kpcyrd @Nihlus what do you think of e422594 ? The old API needed build_id, artifact_id and diffoscope_id to create the diffoscope link. Adding the artifact_id to the transtion_packages API would be a bit against the point of reducing overhead, so I think this new diffoscope endpoint is the best compromise.

[Nihlus]

I think adding API endpoints for more direct data access when you have an ID already (diffoscope, build log, artifact, etc) is a fine idea - the existing endpoints follow the data model, but I see several benefits to having more direct endpoints as a complement.

Regarding the transition packages API itself, I'm somewhat skeptical as it's a Debian-specific feature (at least how I read it right now) and one of the big efforts we made with the database schema rework was to try and remove as many distro-specific things as possible. I would prefer (with the asterisk that I'm just a contributor, not a maintainer!) that we implement the required functionality in a distro-agnostic fashion or have enough building blocks in the other endpoints that API users can get the required information in other ways.

Something that would get us closer to this without adding anything debian-specific is adding the support for multiple releases/components/etc in query parameters - that would address the first need in #204. Deduplication could theoretically also be added as another query parameter, but I'm less sure of that design choice. Would want input on that.

EDIT: forgot to add - get_build_diffoscope kind of makes the endpoint lie to the end user by only returning the first diffoscope and ignoring any others - there isn't any "canonical" diffoscope for the entire build. Maybe we can concat/combine the diffoscope logs from all the artifacts in some fashion if we want a full-view endpoint?