Comment 2 for bug 1862258

While there may be more to do at the snapcraft build service level, my view on what we should do for this in Launchpad is as follows:

 * Extend `SnapBase` model so that we can specify which architectures are supported by Launchpad for a given base, probably by creating a new `SnapBaseArch` table and some helper properties on `SnapBase` to link things together (compare `ArchiveArch` and `Archive.processors`).
 * Extend either `Snap.requestBuildsFromJob` or `lp.snappy.adapters.buildarch.determine_architectures_to_build` to intersect the set of architectures supported by the base. (We already intersect explicit configuration in the snap recipe with any architecture configuration in snapcraft.yaml; the latter is preferred nowadays, but didn't exist when we first implemented snap building in Launchpad.)
 * Possibly change `Snap.requestBuild` to explicitly reject attempts to build a snap for an incompatible base/architecture combination.

If we do this, the common case will just work: we won't dispatch i386 builds for core20, since attempting to do so won't work. New architectures will also work naturally in a similar way.

It's possible that we may also want to explicitly flag that snapcraft.yaml requested architectures that aren't supported with the given base. My preference would be for this to be indicated somewhere where the user is more likely to see it, perhaps by `snapcraft` itself, but I'm open to doing it in Launchpad as well if we think that would be helpful. If we do this, then I think it should be in a "soft" way: that is, we should still dispatch builds for architectures that make sense, but we should indicate it in the list of recent builds. This may tie in to @twom's recent work on improving the presentation of build sets.