Proposed pocket racing uninstallability and SRU verification around release time

[Robie Basak]

I just filed this bug: https://bugs.launchpad.net/ubuntu/+bug/1634201; I
Cc'd the bug so as to try and not fragment any discussion.

During development, we have packages in -proposed that fail to migrate,
as expected, for good reason.

At release time, these packages are still present. For example, Yakkety
released with libhcrypto4-heimdal:amd64 1.7~git20160703+dfsg-1 in
proposed, which is not in the release pocket because it is broken (see
bug 1617963).

I think we should be encouraging users to volunteer to risk testing
proposed in stable releases. This helps with SRU verification.

However, our current release process breaks these users when they
upgrade to a new release (which, given that they are testing the cutting
edge, they are likely to do early, before the proposed pocket has been
cleaned out).

This means that users, instead of being encouraged, are being
discouraged from testing the SRU proposed pocket since we are breaking
them with known bugs but delaying removal of those breakages.

Bug 1633653 is an example: a user with xenial-proposed enabled upgraded
to Yakkety one day after release, and this broke.

How can we adjust our release process to stop this happening?