test for ddm compatibility with the most recent release

[ahl]

In January we hit a snag during dogfood update due to a change in the ddm protocol. Both switch zones are up during upgrade which means that mid-upgrade we have both new and old code running simultaneously (this will be generally true as the upgrade feature progresses, but is specifically true for the switch zones today). To address this, we mode v2 of the ddm protocol compatible with v1:

• backwards compatibility with ddm protocol version 1 #156

This PR also introduced a test to validate compatibility between v1 and v2. Since we've shipped v2 and upgraded customers to v2, the validation of compatibility between v1 and v2 is no longer relevant. Instead, we need a mechanism to validate the current code in development against the releases from which upgrade is supported (Note: to this point we have only supported incremental upgrade from N to N+1; we have not supported skipping a release e.g. N to N+2). This kind of validation from release to release is going to be generally relevant (i.e. for omicron) as our upgrade process evolves to have both new and old code running side-by-side for other services.

This testing is going to be particularly helpful for validating our solution to

• ddm protocol version negotiation #157

Here are some discrete steps we can take:

• Remove or disable the current v1 -> v2 tests as the validation they perform is no longer relevant (disable the ddm v1 tests #276)
• Determine a mechanism for tagging and discovering previous version(s). Currently we've hard-coded a particular hash to retrieve buildomat artifacts from a known-valid v1 build. This was appropriately expedient, but a more general approach may be warranted such as doing discovery from a list of tagged, TUF repos, tagging this and other repos at the time of a new software release, etc.
• Figure out how we want to support an old client version so that new code can communicate with a ddmadm from a previous release