UI test fails in 2022 #13086

<!-- Describe the issue -->

When building the openSUSE bitcoin package, build fails after 2022-12-08 because the testsuite has one FAIL in ./src/qt/test/paymentservertests.cpp that fails to verify a cert that expires in 2022 after 10y.

<!--- What behavior did you expect? -->

would be nice to be able to build (and test) bitcoin software at any time

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

test failed with

QWARN  : PaymentServerTests::paymentServerTests() PaymentRequestPlus::getMerchant: Payment request: certificate expired or not yet active:  QSslCertificate("3", "01", "Ipbt+DxK8RDQd25/5ueXqw==", (), ("Payment Request Test Merchant"), QMap(), QDateTime(2012-12-10 16:37:24.000 UTC Qt::TimeSpec(UTC)), QDateTime(2022-12-08 16:37:24.000 UTC Qt::TimeSpec(UTC)))
FAIL!  : PaymentServerTests::paymentServerTests() Compared values are not the same

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

openSUSE has bitcoin-0.16.0

<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

<!-- Any extra information that might be useful in the debugging process. -->

<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

Ah, Bitcoin Core not supporting time traveling yet!

@NicolasDorier you mean Bitcoin?

May have relevance if a wallet.dat is in cold storage. Shouldn't assume that an upgrade path for the wallet will be available without building each version and upgrading it incrementally unless full incremental upgrade scripts or full backward compatibility for wallet.dat is GUARANTEED in all future versions.

It should be possible to get a Bitcoin Core v0.1 wallet out of cold storage in the year 2050 and use it.

Shouldn't assume that an upgrade path for the wallet will be available without building each version and upgrading it incrementally unless full incremental upgrade scripts or full backward compatibility for wallet.dat is GUARANTEED in all future versions.

That sounds Kafkaesque. Have you ever noticed what nightmare it is to build old software on new platforms? We've always tried to keep wallet backwards compatibility as far back as possible. (and if there is ever going to be a completely new wallet format, a strong requirement is indeed to have upgrade scripts)

I thought there was a note I saw recently about not skipping (all in-between) versions when upgrading due to wallet upgrade - may have imagined it.

Fixed in 3548e4aac72e9148d41b440052a89d89328f7661