Poor buildfarm coverage of strong-random alternatives

I just noticed that, since I retired pademelon in August, we have
exactly no buildfarm coverage of --disable-strong-random code paths.
What's more, because the vast majority of the buildfarm enables
--with-openssl, we're mostly just testing the punt-to-OpenSSL
variant of pg_strong_random. Checking the buildfarm database,
the last builds that did anything different from that are

protosciurus | 2018-08-15 13:37:08 | checking which random number source to use... /dev/urandom
pademelon | 2018-08-16 18:47:07 | checking which random number source to use... weak builtin PRNG
castoroides | 2018-09-26 12:03:07 | checking which random number source to use... /dev/urandom
locust | 2018-12-14 01:14:35 | checking which random number source to use... /dev/urandom
frogfish | 2018-12-22 18:39:35 | checking which random number source to use... /dev/urandom
anole | 2018-12-27 10:30:33 | checking which random number source to use... /dev/urandom
gharial | 2018-12-27 13:30:46 | checking which random number source to use... /dev/urandom
jacana | 2018-12-27 13:45:14 | checking which random number source to use... Windows native

Do we need more coverage of the "Windows native" alternative?

More urgently, what about the lack of --disable-strong-random
coverage? I feel like we should either have a buildfarm
critter or two testing that code, or decide that it's no longer
interesting and rip it out. backend_random.c, to name just
one place, has a complex enough !HAVE_STRONG_RANDOM code path
that I don't feel comfortable letting it go totally untested.

There's certainly a reasonable argument to be made that everybody
should have /dev/urandom these days, or else be willing to
install OpenSSL and let it figure out what to do. (Even my hoary
old HPUX 10.20 box does have OpenSSL and a working entropy daemon
to feed it; I was just intentionally not using that in the
pademelon configuration.)

regards, tom lane