base: core20 snap builds are dispatched for i386, which always fails

[Ian Johnson]

When building snaps on LP, (and also through build.snapcraft.io where I first discovered this), there is not an obvious error that happens when one tries to build a snap with base: core20 on architecture i386. I think that LP should more clearly complain when this happens, currently I see this kind of error:

```
linux32: failed to execute snap: No such file or directory
Install failed
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 259, in run
    self.install()
  File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 163, in install
    snap_name])
  File "/usr/lib/python2.7/dist-packages/lpbuildd/target/lxd.py", line 536, in run
    subprocess.check_call(cmd, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['lxc', 'exec', 'lp-focal-i386', '--', 'linux32', 'snap', 'install', '--channel=stable', 'core20']' returned non-zero exit status 127
```

I assume this specific error happens because lp-focal-i386 exists and is otherwise a fine image but has a broken snapd/core20 snap or doesn't have snapd/core20 snap at all on it?

See also https://bugs.launchpad.net/snapcraft/+bug/1862256 for the snapcraft side of this problem.

[Sergio Schvezov (sergiusens)]

This also affects build -> https://github.com/canonical-web-and-design/snapcraft.io/issues/2905

[Colin Watson (cjwatson)]

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.

[Colin Watson (cjwatson)]

core20 builds will no longer be dispatched for i386.