[Swan] test case aborts, such as ikev2-x509-14-san-dn-mismatch

[Paul Wouters]

I looked at the many slow failures we are seeing for tests that are
supposed to fail to establish a connection. the test harnass now
times out on these, eg:

https://testing.libreswan.org/v3.27-930-g9df3f69c7-master/ikev2-x509-14-san-dn-mismatch

The issue is that the last retransmit before we release the hack is at 32s:

010 "san" #2: STATE_PARENT_I2: retransmission; will wait 32 seconds for response
002 "san" #2: certificate verified OK: E=user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA
003 "san" #2: ID_DER_ASN1_DN 'E=user-east at testing.libreswan.org,CN=east.testing.libreswan.org,OU=Test Department,O=Libreswan,L=Toronto,ST=Ontario,C=CA' does not match expected 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=NOTeast.testing.libreswan.org, E=user-NOTeast at testing.libreswan.org'
002 "san" #2: Peer public key SubjectAltName does not match peer ID for this connection
002 "san" #2: X509: CERT payload does not match connection ID
224 "san" #2: STATE_PARENT_I2: v2N_AUTHENTICATION_FAILED
002 "san" #2: deleting other state #2 (STATE_PARENT_I2) and NOT sending notification
002 "san" #1: deleting state (STATE_PARENT_I2) and NOT sending notification

The 32s is putting us over the 60s wait period in the python expect
code and thus causing the failure.

The old behaviour was to error after the first AUTH failed:

002 "san" #2: Peer public key SubjectAltName does not match peer ID for this connection
002 "san" #2: X509: CERT payload does not match connection ID
224 "san" #2: STATE_PARENT_I2: v2N_AUTHENTICATION_FAILED
031 "san" #2: STATE_PARENT_I2: 10 second timeout exceeded after 0 retransmits.  Possible authentication failure: no acceptable response to our first encrypted message
000 "san" #2: starting keying attempt 2 of an unlimited number, but releasing whack
west #


I the think old behaviour was correct. The AUTH payload failed but not
because of a failure of encryption or integrity. It is simply not
allowed to because it is the wrong IKE ID. There won't be coming a
better answer on this exchange. It is not a forged/bad packet.

I'll redo a git bisect tomorrow and see why it changed.

Paul