Buildbot could use a distro version update

[rincebrain]

(I'm happy to twiddle this in my still-for-a-bit-copious free time if anyone likes...)

Currently, we build against:

• Centos 7 {x86_64} (build+test)
• Centos 8 {x86_64} (build+test)
• Centos 8 Stream {x86_64} (build+test)
• Debian 8 {armel, ppc64} (build)
• Debian 10 {arm64,x86_64} (build)
• Fedora 33 {x86_64} (build+test)
• FBSD {12,13,14}-CURRENT snapshots {x86_64} (build+test)
• Kernel.org git tip builtin {x86_64} (build)
• Ubuntu {16.04} {i386} (build)
• Ubuntu {18.04, 20.04} {x86_64} (build+test)

I would suggest at a minimum adding:

• Some CentOS 8 alternative that will keep getting updates after 2021, be it Rocky or Alma or w/e {x86_64} (build+test) Whoops, missed Use Almalinux 8 AMI in place of CentOS 8 #234. Nice.
• Debian 11 {arm64,x86_64} (build+test)
• Fedora 35 {x86_64} (build+test)
• FreeBSD something {not little-endian} (build+test)

It might also be useful to add a couple weirder things like:

• Some Linux (kernel and OpenZFS built with Clang) (build and test)
• Some Linux (kernel + OpenZFS built with KASAN) (build and test)

Though unless you could source somewhere for regularly built Clang kernels, that could be a significant burden, and building the whole kernel and then running the test suite each time could suck...maybe a bot that runs once a day/week against master, or doesn't block merges (e.g. best effort) would be better for one or both of those?

I'd also like to know whether there's a reason not to just make at least the non-x86_64 buildbots testbots too? Does it just take far too long?

I don't know when people want to drop support for older things, so I don't know when it would make sense to drop the Debian 8 trees. (It might also make sense to try using ELTS for armel if we want to see what some users might likely be running and not just "old kernel", though it's not available for ppc64, and that should probably involve a recurring payment to Freexian if using it in a non-personal setting...)

The FBSD/something BE suggestion is because it'd be nice to make sure the FBSD codepaths don't somehow have BE-specific issues. I'd suggest sparc64 for the variety (and because of openzfs/zfs#12008 not being noticed for a long time), but sourcing a build slave for that that would finish runs before the sun burns out could prove tricky, and qemu is...not amazing at sparc64. (I also don't know how the ppc64 slaves are done from quickly looking at the config, so I don't know if that's just paying the qemu cost or actual machines hosted somewhere or if there's a source for ppc64 VMs somewhere...)

Just some thoughts. Not exactly the highest priority, but keeps coming to mind periodically.

[sideeffect42]

Maybe Adélie Linux could replace the Debian 8 big endian Power(PC) builder.
Adélie Linux supports Power(PC) in big endian mode, they don't yet have ZFS packages, though.