pg_upgrade and cross-library upgrades

Hi all,

After removing --with-openssl from its build of HEAD, snapper has
begun failing in the pg_upgrade path 11->HEAD, because it attempts
pg_upgrade from binaries that have OpenSSL to builds without it:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=snapper&br=HEAD

Using the TAP tests of pg_upgrade, I can get the same failure with the
following steps:
1) Setup instance based on Postgres 11, compiled with OpenSSL.
2) Run a few tests and tap a dump:
# From 11 source tree:
make installcheck
cd contrib/pgcrypto/
USE_MODULE_DB=1 make installcheck
~/path/to/11/bin/pg_dumpall -f /tmp/olddump.sql
3) From 16~ source tree, compiled without OpenSSL:
cd src/bin/pg_upgrade
olddump=/tmp/olddump.sql oldinstall=~/path/to/11/ make check

And then you would get:
could not load library "$libdir/pgcrypto": ERROR: could not access
file "$libdir/pgcrypto": No such file or directory
In database: contrib_regression_pgcrypto

The same thing as HEAD could be done on its back-branches by removing
--with-openssl and bring more consistency, but pg_upgrade has never
been good at handling upgrades with different library requirements.
Something I am wondering is if AdjustUpgrade.pm could gain more
knowledge in this area, though I am unsure how much could be achieved
as this module has only object-level knowledge.

Anyway, that's not really limited to pgcrypto, any extension with
different cross-library requirements would see that. One example,
xml2 could be compiled with libxml and without libxslt. It is less
popular than pgcrypto, but the failure should be the same.

I'd rather choose the shortcut of removing --with-openssl from snapper
in the short term, but that does nothing for the root issue in the
long-term.

Thoughts?
--
Michael