Don't fail if the PSK identity doesn't match

[mattcaswell]

In 1.1.0 s_server if the PSK identity doesn't match what we have then
a warning is printed and we continue the connection anyway. In 1.1.1,
if TLSv1.3 is used and the identity doesn't match then we abort the
connection. We should really be consistent with the old behaviour.

Checklist

• documentation is added or updated
• tests are added or updated

[kaduk]

There is some guidance in the TLS 1.3 spec on this topic; let me pull it up.

[kaduk]

Ah, this is just in s_server anyway, not in the library core.

The text I was looking for is:

   Implementor's note: When session resumption is the primary use case
   of PSKs, the most straightforward way to implement the PSK/cipher
   suite matching requirements is to negotiate the cipher suite first
   and then exclude any incompatible PSKs.  Any unknown PSKs (e.g., they
   are not in the PSK database or are encrypted with an unknown key)
   SHOULD simply be ignored.  If no acceptable PSKs are found, the
   server SHOULD perform a non-PSK handshake if possible.  If backward
   compatibility is important, client-provided, externally established
   PSKs SHOULD influence cipher suite selection.

and also in the appendices:

   Because implementations respond to an invalid PSK binder by aborting
   the handshake, it may be possible for an attacker to verify whether a
   given PSK identity is valid.  Specifically, if a server accepts both
   external-PSK handshakes and certificate-based handshakes, a valid PSK
   identity will result in a failed handshake, whereas an invalid
   identity will just be skipped and result in a successful certificate
   handshake.  Servers which solely support PSK handshakes may be able
   to resist this form of attack by treating the cases where there is no
   valid PSK identity and where there is an identity but it has an
   invalid binder identically.

But it looks like those don't conflict with what we're doing here, so please go ahead.

[mattcaswell]

This got pushed. Closing.