fix: fix the order of arguments to merge_openpgp_certificates() call

This fixes flaky tests/test_securejoin.py::test_qr_scan_updates_new_relay_address
which hanged during the second securejoin on fast network (e.g. when testing against local container)
as Bob received securejoin pubkey message from Alice but did not merge the new relay list.

src/contact.rs

@@ -372,7 +372,11 @@ pub(crate) async fn import_public_key(
         .await?
     {
         let old_public_key = SignedPublicKey::from_slice(&public_key_bytes)?;
-        merged_public_key = merge_openpgp_certificates(public_key.clone(), old_public_key)
+
+        // Order of merge_openpgp_certificates() arguments is important.
+        // Second argument is the new key, it is preferred in case of ties,
+        // i.e. same signature timestamps.
+        merged_public_key = merge_openpgp_certificates(old_public_key, public_key.clone())
             .context("Failed to merge public keys")?;
         &merged_public_key
     } else {

src/pgp.rs

@@ -382,6 +382,8 @@ pub fn symm_encrypt_message(
 /// or even have some packets maliciously dropped
 /// (for example, all encryption subkeys dropped)
 /// or restored from some older version of the certificate.
+///
+/// In case of ties, i.e. same timestamps, data from the new certificate is preferred.
 pub fn merge_openpgp_certificates(
     old_certificate: SignedPublicKey,
     new_certificate: SignedPublicKey,